On Wed, Aug 24, 2016 at 2:34 AM, Levente Uzonyi <leves at caesar.elte.hu> 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.

Just to be pedantic ;) IIUC... #yield does not allow lower priority
processes to run. For that you need to #wait, #suspend or be waiting
on a #critical:  etc.

cheers -ben

> 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 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. :-)
>>
>>
>>
>