[squeak-dev] Re: Using Semaphores in drawing code
marcel.taeumel
Marcel.Taeumel at hpi.de
Wed Aug 24 06:35:41 UTC 2016
Ben Coman wrote
> On Wed, Aug 24, 2016 at 2:34 AM, Levente Uzonyi <
> leves at .elte
> > 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@
> >
>>> 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. :-)
>>>
>>>
>>>
>>
Yes, only waiting on a semaphore (or mutex) will allow processes at lower
priorities to run. For example, "(Delay forMilliseconds: 500) wait." gives
processes at the same or lower priorities a chance to run. You can implement
interesting process schedulers with this. :D
Best,
Marcel
--
View this message in context: http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912413.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
More information about the Squeak-dev
mailing list
|