On Wed, May 06, 2009 at 05:50:09PM +0200, Trygve Reenskaug wrote:
> Image is Squeak3.10.gamma.7159.
> 
> 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?

Morphic does everything in its own main UI process, but none of the things
that happen in that process are necessarily "thread safe". If you want some
other process (such as the process in which your animation is running) to do
things in the Morphic UI process, then your animation process should schedule
things to be executed:

  WorldState addDeferredUIMessage: [doSomethingInTheMorphicUIProcess]

This causes #doSomethingInTheMorphicUIProcess to be evaluated shortly
thereafter in the context of the Morphic UI process, hence no crashes.

I have not tried this with MorphicEventDispatcher>>dispatchDefault:with:,
but I expect that wrapping the call in #addDeferredUIMessage: may take
care of your problem.

Dave