Levente Uzonyi wrote
> You have to #yield explicitly if you want your process to be preempted. 
> Otherwise, processes with the same or lower priority will never run.
> It's not a Semaphore change, but a VM setting.
> 
> Levente
> 
> On Tue, 23 Aug 2016, Ben Coman wrote:
> 
>> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <

> Marcel.Taeumel@

> > 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 <
>>>
>>>> marcel.taeumel@
>>>
>>>> > 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. :-)
>>
>>

The problem is that there can be dead-locked drawing code in a morph without
a chance to flag that morph for not being drawn at the next round. It would
be nice if we could address that problem in the future.

Best,
Marcel



--
View this message in context: http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912378.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.