On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> Chris Muller-3 wrote
>> 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 &lt;
>
>> marcel.taeumel@
>
>> &gt; 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
>>>
>>>
>>>
>>>
>>>
>>>
>
> Hi Chris, hi Bert,
>
> if you need an example, well, Etoys/Kedama makes those things in the latest
> Trunk version. ;-)
>
> It is not the point whether applications should do this or not but our
> recently changed semantics of semaphores might render your image unusable
> because of unusual application code.

I'm curious what was the change in Semaphore semantics?

cheers -ben

> I see an opportunity to improve
> Morphics robustness and help users debug their applications without image
> freeze/lock out.
>
> So, I want to discuss here, whether there could be a Notification sent
> whenever an object/process starts waiting on a semaphore. :-)