On Wed, 24 Aug 2016, Ben Coman wrote:

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

That's correct.

Levente

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