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