Using Semaphores in drawing code
Locked
12
12
Using Semaphores in drawing code
 
|
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 |
Re: Using Semaphores in drawing code
|
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 > > > > > > |
Re: Using Semaphores in drawing code
|
|
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 Right. - Bert - |
|
|
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 >> >> >> >> >> >> > |
Re: Using Semaphores in drawing code
|
|
In reply to this post by Chris Muller-3
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 |
|
|
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. :-) |
Re: Using Semaphores in drawing code
|
|
Seems to be more strict/reliable now. Does real blocking. Something in that direction. :-) Best, Marcel |
|
|
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 < >>> 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 |
Re: Using Semaphores in drawing code
|
|
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 < >> >>> 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. :-) > > |
Re: Using Semaphores in drawing code
|
|
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 |
|
|
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 < >>> >>> >>>> 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. :-) >> >> >> > |
Re: Using Semaphores in drawing code
|
|
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 |
Re: Using Semaphores in drawing code
|
|
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 < >>>> >>>> >>>>> 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. :-) >>> >>> >>> >> > > |
Re: Using Semaphores in drawing code
|
|
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 < > >> 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. > |
Re: Using Semaphores in drawing code
|
|
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 |
Re: Using Semaphores in drawing code
|
|
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 |
Re: Using Semaphores in drawing code
|
|
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. > > |
Re: Using Semaphores in drawing code
|
|
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 |
Re: Using Semaphores in drawing code
|
|
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 > > |
Re: Using Semaphores in drawing code
|
|
Okay, that just leaves the job to an additional watcher process. Self did that, too. Best, Marcel |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |