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

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.