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