Using Semaphores in drawing code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Using Semaphores in drawing code

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





Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Chris Muller-3
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 <[hidden email]> 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
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Bert Freudenberg
On Mon, Aug 22, 2016 at 6:00 PM, Chris Muller <[hidden email]> 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?

Right.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Ben Coman
In reply to this post by Chris Muller-3
Unless your model includes a large calculation running in another
thread.  I would *guess* the right way to approach this is for the
calculation-thread to periodically create a custom
display-context-object containing only simple objects like Integers
and Strings, then never touch that object again after assigning it to
an instance variable as an atomic action.  Perhaps a good application
for an immutable object.

cheers -ben

On Tue, Aug 23, 2016 at 12:00 AM, Chris Muller <[hidden email]> 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 <[hidden email]> 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
>>
>>
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
In reply to this post by Chris Muller-3
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Ben Coman
On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]> 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 &lt;
>
>> marcel.taeumel@
>
>> &gt; 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'm curious what was the change in Semaphore semantics?

cheers -ben

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

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
Ben Coman wrote
On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]> 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'm curious what was the change in Semaphore semantics?

cheers -ben

> 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. :-)
Seems to be more strict/reliable now. Does real blocking. Something in that direction. :-)

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Ben Coman
On Tue, Aug 23, 2016 at 9:34 PM, marcel.taeumel <[hidden email]> wrote:

> Ben Coman wrote
>> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel &lt;
>>> 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'm curious what was the change in Semaphore semantics?
>>
>> cheers -ben
>>
>
> Seems to be more strict/reliable now. Does real blocking. Something in that
> direction. :-)

I search my gmail for...    semaphore "The Trunk Kernel"

and could not identify any changes to Semaphore handling.  I did see
two Process related commits that seem aimed at improving the run queue
interaction with semaphores, but I'm not sure that is what you meant.

http://forum.world.st/The-Trunk-Kernel-eem-999-mcz-td4878765.html
Name: Kernel-eem.999
Author: eem
Time: 18 February 2016, 11:03:09.008076 pm
UUID: 30222068-755f-4637-bbbb-6f775291e746
Ancestors: Kernel-bf.998
Fix isSuspended (my last commit was a regression; I had confused
isSuspended with isBlocked).  Comment all the isFoo testing methods in
process.  Add isBlocked.  Modify Process>>terminate to set the pc of
the context of a process that is not auto-terminated to its endPC so
that isTerminated and isSuspended can distinguish between processes
either terminated or suspended.

http://forum.world.st/The-Trunk-Kernel-eem-1000-mcz-td4878768.html
Name: Kernel-eem.1000
Author: eem
Time: 18 February 2016, 11:18:00.405861 pm
UUID: 70e6b96c-ca2f-4f79-8253-239575f13beb
Ancestors: Kernel-eem.999
Make Process>>resume primitive.  Andreas fixed the ancestor of the Cog
VM so that the resume primitive fails if thesuspendedContext is not a
context.  This renders Tim's suspendedCOntext ifNil: [^self
primitiveFailed] guard obsolete.  Hence nuke primitiveResume.


Also searching on...     semaphore "vm-dev vm maker"
could not identify any Semaphore changes.

If indeed there were any Semaphore code changes, I'd be interested in
reviewing them if anyone could easily put their finger on it.

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Levente Uzonyi
In reply to this post by Ben Coman
You have to #yield explicitly if you want your process to be preempted.
Otherwise, processes with the same or lower priority will never run.
It's not a Semaphore change, but a VM setting.

Levente

On Tue, 23 Aug 2016, Ben Coman wrote:

> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]> 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 &lt;
>>
>>> marcel.taeumel@
>>
>>> &gt; 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'm curious what was the change in Semaphore semantics?
>
> cheers -ben
>
>> 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. :-)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
Levente Uzonyi wrote
You have to #yield explicitly if you want your process to be preempted.
Otherwise, processes with the same or lower priority will never run.
It's not a Semaphore change, but a VM setting.

Levente

On Tue, 23 Aug 2016, Ben Coman wrote:

> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]> 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'm curious what was the change in Semaphore semantics?
>
> cheers -ben
>
>> 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. :-)
>
>
The problem is that there can be dead-locked drawing code in a morph without a chance to flag that morph for not being drawn at the next round. It would be nice if we could address that problem in the future.

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Ben Coman
In reply to this post by Levente Uzonyi
On Wed, Aug 24, 2016 at 2:34 AM, Levente Uzonyi <[hidden email]> wrote:
> You have to #yield explicitly if you want your process to be preempted.
> Otherwise, processes with the same or lower priority will never run.

Just to be pedantic ;) IIUC... #yield does not allow lower priority
processes to run. For that you need to #wait, #suspend or be waiting
on a #critical:  etc.

cheers -ben

> It's not a Semaphore change, but a VM setting.
>
> Levente
>
>
> On Tue, 23 Aug 2016, Ben Coman wrote:
>
>> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]>
>> 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 &lt;
>>>
>>>
>>>> marcel.taeumel@
>>>
>>>
>>>> &gt; 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'm curious what was the change in Semaphore semantics?
>>
>> cheers -ben
>>
>>> 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. :-)
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
Ben Coman wrote
On Wed, Aug 24, 2016 at 2:34 AM, Levente Uzonyi <[hidden email]> wrote:
> You have to #yield explicitly if you want your process to be preempted.
> Otherwise, processes with the same or lower priority will never run.

Just to be pedantic ;) IIUC... #yield does not allow lower priority
processes to run. For that you need to #wait, #suspend or be waiting
on a #critical:  etc.

cheers -ben

> It's not a Semaphore change, but a VM setting.
>
> Levente
>
>
> On Tue, 23 Aug 2016, Ben Coman wrote:
>
>> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]>
>> 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'm curious what was the change in Semaphore semantics?
>>
>> cheers -ben
>>
>>> 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. :-)
>>
>>
>>
>
Yes, only waiting on a semaphore (or mutex) will allow processes at lower priorities to run. For example, "(Delay forMilliseconds: 500) wait." gives processes at the same or lower priorities a chance to run. You can implement interesting process schedulers with this. :D

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Levente Uzonyi
In reply to this post by Ben Coman
On Wed, 24 Aug 2016, Ben Coman wrote:

> On Wed, Aug 24, 2016 at 2:34 AM, Levente Uzonyi <[hidden email]> wrote:
>> You have to #yield explicitly if you want your process to be preempted.
>> Otherwise, processes with the same or lower priority will never run.
>
> Just to be pedantic ;) IIUC... #yield does not allow lower priority
> processes to run. For that you need to #wait, #suspend or be waiting
> on a #critical:  etc.

That's correct.

Levente

>
> cheers -ben
>
>> It's not a Semaphore change, but a VM setting.
>>
>> Levente
>>
>>
>> On Tue, 23 Aug 2016, Ben Coman wrote:
>>
>>> On Tue, Aug 23, 2016 at 5:26 PM, marcel.taeumel <[hidden email]>
>>> 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 &lt;
>>>>
>>>>
>>>>> marcel.taeumel@
>>>>
>>>>
>>>>> &gt; 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'm curious what was the change in Semaphore semantics?
>>>
>>> cheers -ben
>>>
>>>> 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. :-)
>>>
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Chris Muller-3
In reply to this post by marcel.taeumel
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 <[hidden email]> 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 &lt;
>
>> marcel.taeumel@
>
>> &gt; 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Levente Uzonyi
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 &lt;
>
>>> Marcel.Taeumel@
>
>>> &gt; 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 &lt;
>>>>
>>>>> marcel.taeumel@
>>>>
>>>>> &gt; 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

David T. Lewis
In reply to this post by Chris Muller-3
On Wed, Aug 24, 2016 at 11:21:39AM -0500, Chris Muller 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..

It is good style to use Project current addDeferredUIMessage: rather
than WorldState addDeferredUIMessage:

Of course we are talking about Morphic here, but still ...

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

Chris Muller-3
Okay, that's fine, my broader point just wondering whether that
existing mechanism is sufficient for Marcel's multi-Process situation,
or whether there really is a need to introduce yet another one into
Morphic.

We know it has to be syncrhonized anyway at the bottom, right? -- its
not going to be multitasking in multiple drawing primitives
simultaneously, the synchronization must occur at a higher level, and
there is an existing higher-level mechanism to do that..

On Wed, Aug 24, 2016 at 4:39 PM, David T. Lewis <[hidden email]> wrote:

> On Wed, Aug 24, 2016 at 11:21:39AM -0500, Chris Muller 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..
>
> It is good style to use Project current addDeferredUIMessage: rather
> than WorldState addDeferredUIMessage:
>
> Of course we are talking about Morphic here, but still ...
>
> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Using Semaphores in drawing code

marcel.taeumel
Chris Muller-3 wrote
Okay, that's fine, my broader point just wondering whether that
existing mechanism is sufficient for Marcel's multi-Process situation,
or whether there really is a need to introduce yet another one into
Morphic.

We know it has to be syncrhonized anyway at the bottom, right? -- its
not going to be multitasking in multiple drawing primitives
simultaneously, the synchronization must occur at a higher level, and
there is an existing higher-level mechanism to do that..

On Wed, Aug 24, 2016 at 4:39 PM, David T. Lewis <[hidden email]> wrote:
> On Wed, Aug 24, 2016 at 11:21:39AM -0500, Chris Muller 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..
>
> It is good style to use Project current addDeferredUIMessage: rather
> than WorldState addDeferredUIMessage:
>
> Of course we are talking about Morphic here, but still ...
>
> Dave
>
>
Okay, that just leaves the job to an additional watcher process. Self did that, too.

Best,
Marcel
12