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

Levente Uzonyi leves at caesar.elte.hu
Thu Aug 25 21:24:34 UTC 2016


On Thu, 25 Aug 2016, marcel.taeumel wrote:

> Levente Uzonyi wrote
>> On Wed, 24 Aug 2016, marcel.taeumel wrote:
>>
>>> 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."
>>
>> Exception handling, especially in Cog/Spur, is expensive. Frames have to
>> be created, marked, walked.
>>
>> Levente
>>
>>>
>>> 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.
>>>
>>>
>
> Hi Levente,
>
> with "expensive" you mean "not optimized", right? I am asking because we use

It may not cause noticable slowdown, especially on a fast machine, but 
it has a rather high overhead compared to not using it. The better the JIT 
gets, the higher the overhead will be. I vaguely remember that in 
javascript it can be up to 2000 times slower.

> our exception mechanism for accessing source code and I also know about a
> game that used Notifications as a core communication concept in a game. :-)
>
> --> CurrentReadOnlySourceFiles

I wanted to change CurrentReadOnlySourceFiles to be a ProcessLocalVariable 
when they got added to the Trunk, but it's not an easy thing to do, 
especially through the updater.

Levente

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


More information about the Squeak-dev mailing list