Using Semaphores in drawing code
Locked
12
12
Re: Using Semaphores in drawing code
 
|
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 |
Re: Using Semaphores in drawing code
|
Marcel,
if we could think of a good way to detect the lockup we should definitely add it. Raising a signal every time a process waits on a semaphore is definitely not a good way. Having a watchdog process monitoring the UI process sounds a lot better. But maybe there are other ideas. If we had a concrete proposal this might become a more fruitful discussion :) - Bert - On Thu, Aug 25, 2016 at 9:05 AM, marcel.taeumel <[hidden email]> wrote: Hi Levente, |
Re: Using Semaphores in drawing code
|
|
In reply to this post by marcel.taeumel
On Thu, 25 Aug 2016, marcel.taeumel wrote:
> Levente Uzonyi wrote >> On Wed, 24 Aug 2016, marcel.taeumel wrote: >> >>> marcel.taeumel wrote >>>> >>>> Chris Muller-3 wrote >>>>> Hi Marcel, if you are talking about introducing some kind of code to >>>>> guard against someone mis-using Morphic, then, yes, it *is* a relevant >>>>> point ot the discussion. You can render your image just as unusable >>>>> with >>>>> >>>>> String new become: nil >>>>> >>>>> but we don't want to guard against that.. If Etoys or Kedama are >>>>> doing that, shouldn't they be changed to use WorldState >>>>> addDeferredUIMessage:? That's the SharedQueue designed to let apps >>>>> with background processes append operations to be handled by the UI >>>>> Process.. >>>>> >>>>> On Tue, Aug 23, 2016 at 4:26 AM, marcel.taeumel < >>> >>>>> Marcel.Taeumel@ >>> >>>>> > wrote: >>>>>> Chris Muller-3 wrote >>>>>>> Morphic is designed to run in one Process, so you shouldn't need any >>>>>>> multi-process coordination because you should only be doing drawing >>>>>>> in >>>>>>> the UI process. Right? >>>>>>> >>>>>>> On Mon, Aug 22, 2016 at 9:51 AM, Marcel Taeumel < >>>>>> >>>>>>> marcel.taeumel@ >>>>>> >>>>>>> > wrote: >>>>>>>> Hi, there. >>>>>>>> >>>>>>>> Take this Morph here: >>>>>>>> >>>>>>>> initialize >>>>>>>> super initialize. >>>>>>>> semaphore := Semaphore forMutualExclusion. >>>>>>>> >>>>>>>> step >>>>>>>> semaphore critical: [ [] repeat ]. >>>>>>>> >>>>>>>> drawOn: aCanvas >>>>>>>> semaphore critical: [super drawOn: aCanvas]. >>>>>>>> >>>>>>>> If you create such a morph and open it in the world, the UI process >>>>>>>> will >>>>>>>> freeze because of that endless loop in the step method. Okay. The >>>>>>>> tricky >>>>>>>> thing is, that you cannot use [CMD]+[.] because the drawing code >>>>>>>> waits >>>>>>>> for >>>>>>>> the same semaphore that is currently used in the morph's step. You >>>>>>>> will >>>>>>>> not >>>>>>>> see a debugger appear. The freshly spawned UI process will block >>>>>>>> right >>>>>>>> awai. >>>>>>>> The well known big red cross/box does not appear because there is no >>>>>>>> place >>>>>>>> to detect this situation. >>>>>>>> >>>>>>>> An easy fix would be to tell the application developer to use >>>>>>>> #critical:ifLocked: in that drawing code. If that semaphore is >>>>>>>> really >>>>>>>> necessary. >>>>>>>> >>>>>>>> However, can there be a way for Morphic to detect such issues and >>>>>>>> flag >>>>>>>> that >>>>>>>> Morph for the big red box? (i.e. "morph setProperty: #errorOnDraw >>>>>>>> toValue: >>>>>>>> true") Could there be a notification for the Morphic framework to >>>>>>>> look >>>>>>>> out >>>>>>>> for such as WaitOnCriticalSection to flag that morph as bad? Could >>>>>>>> that >>>>>>>> primitive 86 send such a notification efficiently? Just once? ^__^ >>>>>>>> >>>>>>>> If yes, Morphic could draw its world like this (pseudo code!): >>>>>>>> ... >>>>>>>> [aWorld displayWorld] on: WaitOnCriticalSection do: [:err | >>>>>>>> err "..." findBadMorph "..." setProperty: #errorOnDraw toValue: >>>>>>>> true.] >>>>>>>> ... >>>>>>>> >>>>>>>> Morphic would be more robust. >>>>>>>> >>>>>>>> Best, >>>>>>>> Marcel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> Hi Chris, hi Bert, >>>>>> >>>>>> if you need an example, well, Etoys/Kedama makes those things in the >>>>>> latest >>>>>> Trunk version. ;-) >>>>>> >>>>>> It is not the point whether applications should do this or not but our >>>>>> recently changed semantics of semaphores might render your image >>>>>> unusable >>>>>> because of unusual application code. I see an opportunity to improve >>>>>> Morphics robustness and help users debug their applications without >>>>>> image >>>>>> freeze/lock out. >>>>>> >>>>>> So, I want to discuss here, whether there could be a Notification sent >>>>>> whenever an object/process starts waiting on a semaphore. :-) >>>>>> >>>>>> Best, >>>>>> Marcel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912307.html >>>>>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>>>>> >>>> Hi Chris, >>>> >>>> hehe, interesting comparison. However, waiting on a semaphore is not so >>>> obviously "dumb" as is "String become: nil." If this could be a chance >>>> to >>>> make Morphic more robust without any maintenance or performance >>>> overhead, >>>> we should do it. >>>> >>>> Best, >>>> Marcel >>> >>> Of course, I made that example here very clear and simple for everybody >>> to >>> think about. In bigger projects, however, such code might not look this >>> obvious. The semaphore-wait may just be slipped into drawing code by >>> accident. We can agree that there might usually be no need to wait on >>> semaphores in drawing code. Sure, we never make any mistakes. ;-P We are >>> good programmers. Haha, that's a classic. :-) >>> >>> I regard exception handling as being cheap. Performance-wise. Frameworks >>> with a plentitude of features have to robust wherever possible. We just >>> cannot always point the finger on the application developer and say: >>> "It's >>> just your fault. You are using the environment/framework wrong." >> >> Exception handling, especially in Cog/Spur, is expensive. Frames have to >> be created, marked, walked. >> >> Levente >> >>> >>> Again: No, waiting on a semaphore in drawing code does absolutely NOT >>> compare to "String new become: nil" because using #become: as a strong >>> sent >>> of meta-programming on it while semaphores do not. Well, this is just my >>> opinion. :-) >>> >>> Best, >>> Marcel >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912510.html >>> Sent from the Squeak - Dev mailing list archive at Nabble.com. >>> >>> > > Hi Levente, > > with "expensive" you mean "not optimized", right? I am asking because we use It may not cause noticable slowdown, especially on a fast machine, but it has a rather high overhead compared to not using it. The better the JIT gets, the higher the overhead will be. I vaguely remember that in javascript it can be up to 2000 times slower. > our exception mechanism for accessing source code and I also know about a > game that used Notifications as a core communication concept in a game. :-) > > --> CurrentReadOnlySourceFiles I wanted to change CurrentReadOnlySourceFiles to be a ProcessLocalVariable when they got added to the Trunk, but it's not an easy thing to do, especially through the updater. Levente > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/Using-Semaphores-in-drawing-code-tp4912213p4912555.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > |
|
|
In reply to this post by Bert Freudenberg
On Thu, Aug 25, 2016 at 6:04 PM, Bert Freudenberg <[hidden email]> wrote:
> Marcel, > > if we could think of a good way to detect the lockup we should definitely > add it. > > Raising a signal every time a process waits on a semaphore is definitely not > a good way. > > Having a watchdog process monitoring the UI process sounds a lot better. But > maybe there are other ideas. > > If we had a concrete proposal this might become a more fruitful discussion > :) > > - Bert - >From my industrial automation experience, we'll often set up cross-monitoring watchdogs between two PLCs [1] in different parts of the plant, one setting a bit to 1 and the other setting a bit to 0. If either sees this watchdog-toggle not change for a defined period, a problem is identified with the other. In Squeak's case, the Morphic UI process would cross monitor the watchdog process in case it terminates for some reason. When the watchdog process notices a problem, I guess it would: a. check if the process is on a Semaphore wait queue and remove it b. inject an Exception into the UI process that would operate something like #terminate, but walk the stack back to an appropriate handler and then continue. This could cover more than being blocked on Semaphores, and also scenarios where a long running calculation gets out of control, and also some newcomer errors like "[true] whileTrue" in the Workspace. Although sometimes you want a long running calculation executed from the Workspace. So my questions are: 1. Where would be a good place for the watchdog-toggle variable to live? 2. How can one process inject an Exception into another process? [1] https://en.wikipedia.org/wiki/Programmable_logic_controller. cheers -ben > > On Thu, Aug 25, 2016 at 9:05 AM, marcel.taeumel <[hidden email]> > wrote: >> >> 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 > > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |