[squeak-dev] Re: Using Semaphores in drawing code

marcel.taeumel Marcel.Taeumel at hpi.de
Wed Aug 24 17:13:49 UTC 2016


marcel.taeumel wrote
> 
> 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

Of course, I made that example here very clear and simple for everybody to
think about. In bigger projects, however, such code might not look this
obvious. The semaphore-wait may just be slipped into drawing code by
accident. We can agree that there might usually be no need to wait on
semaphores in drawing code. Sure, we never make any mistakes. ;-P We are
good programmers. Haha, that's a classic. :-)

I regard exception handling as being cheap. Performance-wise. Frameworks
with a plentitude of features have to robust wherever possible. We just
cannot always point the finger on the application developer and say: "It's
just your fault. You are using the environment/framework wrong."

Again: No, waiting on a semaphore in drawing code does absolutely NOT
compare to "String new become: nil" because using #become: as a strong sent
of meta-programming on it while semaphores do not. Well, this is just my
opinion. :-)

Best,
Marcel



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


More information about the Squeak-dev mailing list