[squeak-dev] Re: Using Semaphores in drawing code
marcel.taeumel
Marcel.Taeumel at hpi.de
Wed Aug 24 17:01:44 UTC 2016
Chris Muller-3 wrote
> Hi Marcel, if you are talking about introducing some kind of code to
> guard against someone mis-using Morphic, then, yes, it *is* a relevant
> point ot the discussion. You can render your image just as unusable
> with
>
> String new become: nil
>
> but we don't want to guard against that.. If Etoys or Kedama are
> doing that, shouldn't they be changed to use WorldState
> addDeferredUIMessage:? That's the SharedQueue designed to let apps
> with background processes append operations to be handled by the UI
> Process..
>
> On Tue, Aug 23, 2016 at 4:26 AM, 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 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. :-)
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912307.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
Hi Chris,
hehe, interesting comparison. However, waiting on a semaphore is not so
obviously "dumb" as is "String become: nil." If this could be a chance to
make Morphic more robust without any maintenance or performance overhead, we
should do it.
Best,
Marcel
--
View this message in context: http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912509.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
More information about the Squeak-dev
mailing list
|