From: Damien Cassou I would like to know if the following code is safe:
[SmalltalkImage current snapshot: true andQuit: false] forkAt: Processor userBackgroundPriority
Is there any problem if the main process modifies something in the same time ?
In general it is not safe. Code before the snapshot puts a number of objects into a state suitable for recovery after the image restarts, and code after the snapshot restores them. You also are forking at userBackgroundPriority, which means that the system's tidy-up before a snapshot and recovery after a snapshot could be pre-empted by your own processes, so you might get errors in the main process from a freshly-started image that has only partly recovered when restarted.
Your specific case may not trigger any of the problems - follow the code through the various hooks to see what is affected.
- Peter
Peter Crowther wrote:
From: Damien Cassou I would like to know if the following code is safe:
[SmalltalkImage current snapshot: true andQuit: false] forkAt: Processor userBackgroundPriority
Is there any problem if the main process modifies something in the same time ?
In general it is not safe. Code before the snapshot puts a number of objects into a state suitable for recovery after the image restarts, and code after the snapshot restores them. You also are forking at userBackgroundPriority, which means that the system's tidy-up before a snapshot and recovery after a snapshot could be pre-empted by your own processes, so you might get errors in the main process from a freshly-started image that has only partly recovered when restarted.
Your specific case may not trigger any of the problems - follow the code through the various hooks to see what is affected.
Is it better if I do not fork at all ?
On 30-Jul-06, at 6:02 AM, Damien Cassou wrote:
Peter Crowther wrote:
From: Damien Cassou I would like to know if the following code is safe:
[SmalltalkImage current snapshot: true andQuit: false] forkAt: Processor userBackgroundPriority
Is there any problem if the main process modifies something in the same time ?
In general it is not safe. Code before the snapshot puts a number of objects into a state suitable for recovery after the image restarts, and code after the snapshot restores them. You also are forking at userBackgroundPriority, which means that the system's tidy-up before a snapshot and recovery after a snapshot could be pre-empted by your own processes, so you might get errors in the main process from a freshly-started image that has only partly recovered when restarted. Your specific case may not trigger any of the problems - follow the code through the various hooks to see what is affected.
Is it better if I do not fork at all ?
I strongly urge you to not try saving an image in a background process, except just possibly in a very high priority one. As Peter mentions any other priority can be pre-empted and so all that careful go-to-sleep code (take a look at the fairly scary list of jobs to be done before the actual snapshot) could be completely messed up. That could lead to both the active image and the saved snapshot being unusable, which is unlikely to please you!
Many years ago somebody at a large US automotive manufacturer put a snapshot primitive call into a background process. The resulting debugging work at PPS cost my team 5-6 man-months of effort and a lot of aggravation. Bad idea.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Oh bother" said Pooh, as he reached for the reset button
Tim,
let me understand the difference between the "regular" process priority when a save/+-/quit is done from a menu and when it is done at userBackgroundPriority. In both cases the shutDown list is executed and sensors and processes (and other facilities) are made aware that they must become quiet now because it must be possible for them to come to live on another platform.
If there where any problem(s) at userBackgroundPriority, wouldn't they be the same at the UIProcess's userSchedulingPriority?
Thank you in advance.
/Klaus
P.S. I also cannot understand the original issue, the snapshot primitive does not run faster or slower in background: garbage collection (part of snapshot) and snapshot itself are atomic.
On Sun, 30 Jul 2006 18:09:15 +0200, tim Rowledge tim@rowledge.org wrote:
On 30-Jul-06, at 6:02 AM, Damien Cassou wrote:
Peter Crowther wrote:
From: Damien Cassou I would like to know if the following code is safe:
[SmalltalkImage current snapshot: true andQuit: false] forkAt: Processor userBackgroundPriority
Is there any problem if the main process modifies something in the same time ?
In general it is not safe. Code before the snapshot puts a number of objects into a state suitable for recovery after the image restarts, and code after the snapshot restores them. You also are forking at userBackgroundPriority, which means that the system's tidy-up before a snapshot and recovery after a snapshot could be pre-empted by your own processes, so you might get errors in the main process from a freshly-started image that has only partly recovered when restarted. Your specific case may not trigger any of the problems - follow the code through the various hooks to see what is affected.
Is it better if I do not fork at all ?
I strongly urge you to not try saving an image in a background process, except just possibly in a very high priority one. As Peter mentions any other priority can be pre-empted and so all that careful go-to-sleep code (take a look at the fairly scary list of jobs to be done before the actual snapshot) could be completely messed up. That could lead to both the active image and the saved snapshot being unusable, which is unlikely to please you!
Many years ago somebody at a large US automotive manufacturer put a snapshot primitive call into a background process. The resulting debugging work at PPS cost my team 5-6 man-months of effort and a lot of aggravation. Bad idea.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Oh bother" said Pooh, as he reached for the reset button
On 30-Jul-06, at 10:28 AM, Klaus D. Witzel wrote:
Tim,
let me understand the difference between the "regular" process priority when a save/+-/quit is done from a menu and when it is done at userBackgroundPriority. In both cases the shutDown list is executed and sensors and processes (and other facilities) are made aware that they must become quiet now because it must be possible for them to come to live on another platform.
Correct.
If there where any problem(s) at userBackgroundPriority, wouldn't they be the same at the UIProcess's userSchedulingPriority?
Same problem but higher likelihood of them happening, I think. You might consider some critical section protection to avoid interruptions.
The problem at PPS I mentioned happened because the customer had a background process that ran the snapshot primitive rather than the entire snapshot sequence. Thus the snapshot file on disc had a lot of objects in indeterminate state. Not a happy thing for a payroll processing program.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CAO: Compare Apples to Oranges
On 30-Jul-06, at 9:09 AM, tim Rowledge wrote:
I strongly urge you to not try saving an image in a background process, except just possibly in a very high priority one. As Peter mentions any other priority can be pre-empted and so all that careful go-to-sleep code (take a look at the fairly scary list of jobs to be done before the actual snapshot) could be completely messed up. That could lead to both the active image and the saved snapshot being unusable, which is unlikely to please you!
Many years ago somebody at a large US automotive manufacturer put a snapshot primitive call into a background process. The resulting debugging work at PPS cost my team 5-6 man-months of effort and a lot of aggravation. Bad idea.
Tim, I think the code suggestion from many months ago forks a background unix process that does the snapshot. It of course is an identical copy of the parent at the time of the fork maintained by the magic of virtual memory. The original parent process just keeps running and memory updates don't alter what the child process has. On a mulitple CPU that tosses the repsonsiblity of saving to another process at the cost of memory.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
squeak-dev@lists.squeakfoundation.org