Important Morphic discovery. (was Re: [squeak-dev] Process conflict when redisplaying World)

Trygve Reenskaug trygver at ifi.uio.no
Sun May 10 09:05:47 UTC 2009


Hi Andreas,
Many thanks for helping me along. Your advice to use stepping was sound, 
but didn't quite fit my needs. I tried several alternative solutions 
with running my visualization in a separate process, but they all failed.

This led to an important (in retrospect: obvious) discovery:

I CANNOT CHANGE THE DISPLAYED MORPHS IN A SEPARATE PROCESS.
Reason: Adding, removing, or changing a submorph lead to a call on 
Morph>>layoutChanged which sets fullBounds := nil recursively up the 
owner chain.

At the same time, the normal process is happily repeating 
WorldState>>doOneCycleFor: aWorld. This includes redisplaying the World, 
computing fullBounds if needed.

The separate process can have set fullBounds to nil at any point in the 
redisplay loop. Usually, this has no bad effect, but MNU or 
primitiveError can happen in rare cases. (I run my animation overnight 
to make this happen.) Hence the above conclusion. Two unsynchronized 
processes should not share a common variable. The basic process and my 
process did share the whole morphic display hierarchy.

No apologies for stating the obvious
--Trygve



On 06.05.2009 18:09, Andreas Raab wrote:
> Trygve Reenskaug wrote:
>> I have a visualization demo. It runs in a separate process to permit 
>> mouse and keyboard input while it runs:
>>     startChaosAnimation
>>         currentState = #CHAOS ifTrue: [^self].
>>         currentState := #CHAOS.
>>         processSemaphore wait.
>>             BB2ChaosCtx startChaosAnimationOn: data.
>>             processSemaphore signal.
>>         ] fork.
>>
>> BB2ChaosCtx startChaosAnimationOn: data starts a loop that creates 
>> and removes Morphs interspersed with suitable Delays to get the speed 
>> right.
>>
>> The process can run for several hours before crashing in various 
>> ways. It sometimes crashes with a primitiveError while redisplaying 
>> World. A simpler stop was an MNU in
>>     MorphicEventDispatcher>>dispatchDefault: anEvent with: aMorph
>> where aMorph =  a PasteUpMorph [world], with fullBounds = nil
>>
>> My process is clearly in some unfortunate state when the main process 
>> repaints or handles the mouse. Any ideas how I should make my process 
>> safe?
>
> Use Morph stepping instead of an unsynchronized process.
>
> Cheers,
>   - Andreas
>
>

-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090510/79fad966/attachment.htm


More information about the Squeak-dev mailing list