Morphic is designed to run in one Process, so you shouldn't need any
multi-process coordination because you should only be doing drawing in
the UI process.  Right?

On Mon, Aug 22, 2016 at 9:51 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> Hi, there.
>
> Take this Morph here:
>
> initialize
>    super initialize.
>    semaphore := Semaphore forMutualExclusion.
>
> step
>    semaphore critical: [ [] repeat ].
>
> drawOn: aCanvas
>    semaphore critical: [super drawOn: aCanvas].
>
> If you create such a morph and open it in the world, the UI process will
> freeze because of that endless loop in the step method. Okay. The tricky
> thing is, that you cannot use [CMD]+[.] because the drawing code waits for
> the same semaphore that is currently used in the morph's step. You will not
> see a debugger appear. The freshly spawned UI process will block right awai.
> The well known big red cross/box does not appear because there is no place
> to detect this situation.
>
> An easy fix would be to tell the application developer to use
> #critical:ifLocked: in that drawing code. If that semaphore is really
> necessary.
>
> However, can there be a way for Morphic to detect such issues and flag that
> Morph for the big red box? (i.e. "morph setProperty: #errorOnDraw toValue:
> true") Could there be a notification for the Morphic framework to look out
> for such as WaitOnCriticalSection to flag that morph as bad? Could that
> primitive 86 send such a notification efficiently? Just once? ^__^
>
> If yes, Morphic could draw its world like this (pseudo code!):
> ...
> [aWorld displayWorld] on: WaitOnCriticalSection do: [:err |
>    err "..." findBadMorph  "..." setProperty: #errorOnDraw toValue: true.]
> ...
>
> Morphic would be more robust.
>
> Best,
> Marcel
>
>
>
>
>
>