[squeak-dev] Using Semaphores in drawing code

Marcel Taeumel marcel.taeumel at hpi.de
Mon Aug 22 14:51:18 UTC 2016


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160822/7cbe9580/attachment.htm


More information about the Squeak-dev mailing list