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 at rowledge.org; http://www.rowledge.org/tim
"Oh bother" said Pooh, as he reached for the reset button