[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
|