Sig, Two UI processes polling for input is probably what has happened. I should give some attention to how Dolphin prevents that. Two things that come to mind are raising the priority of a new UI thread to create a modal event loop, and (which Pharo almost certainly does too) starting a new UI thread when needed.
My TimedEvaluator class has headless and "with progres" subclasses. The latter will need some porting, and perhaps the headless one should simply block, or at least do so in Pharo. Terminating the UI thread seems a little harsh, but that might be what is needed. Another option might be to suspend the old UI thread, start the new one, and then undo the damage at the end. Is that something that #forkMainIfMain should do automatically? One of the things that drives me nuts is whether a #suspend would stop the thread that is trying to do the work =:0 Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Sunday, August 16, 2009 5:05 AM To: [email protected] Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/16 Schwab,Wilhelm K <[email protected]>: > Sig, all, > > I have been preparing MC packages with classes and method designed to > soften the blow of moving much of my domain code to Pharo. In this > case, I have some sends of ProcessorSchedler>>forkMainIfMain, so I > created that method. Initially, I made it emtpy, and then based on > what you helpe me find, I tried > > ProcessorScheduler>>forkMainIfMain > Project spawnProcessIfThisIsUI:self activeProcess. > > > The above gets called from something that then immediately waits on a > semaphore that is signalled by one of two threads. One of the threads waits > on a timer, the other tries to evaluate a block; creating a background worker > thread that will run for a limited time. There is a test case that tries > various combinations, some of which should succeed and some should time out. > I have used these things in production in Dolphin for some time. > > In Dolphin, #forkMainIfMain allows the UI to be responsive during these > tests, but trying the above in Pharo turns ugly. There are problems that > appear to related to two UI processes - running short of events or something > like that. The tests run for only a few seconds, though I suppose I could > try to allow enough time to look around, but then I'm probably not the right > person to do the looking anyway. > > DUMB question: the argument to #spawnProcessIfThisIsUI: is named > suspendedProcess. Do I need to ensure the process in question is indeed > suspended before entering the method? If so, then I start wondering how to > get there from #forkMainIfMain, but it's a little late for my brain to take > on that question. > > One thing is certain: what I tried did not work. There were errors from the > event loop and even some screen scarring. > I think, once you spawn a new UI process by your code, you should prevent an old process from returning back to World/WorldState event handling, by simply terminating it after you done. Otherwise, again, take a look what debugger does, when you clicking 'proceed' on a process which being debugged and which was a UI process. It should do some tricks, otherwise you end up with two event loops polling the same event source. > Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Saturday, August 15, 2009 3:29 PM > To: [email protected] > Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? > > 2009/8/15 Schwab,Wilhelm K <[email protected]>: >> Is there anything in Pharo that starts a new main thread to carry on for one >> that is about to get blocked? It might be that Pharo does not need it, >> since sockets are serviced by the VM, where Dolphin (at least prior to >> overlapped calls) did the I/O through the event loop; if the main thread >> stopped, so did Windows event dispatching, and hence no socket I/O. >> > There is such thing. > Try to explore the way how debugger handling this (when process you want to > debug is current UI process), or when you pressing interrupt key. > > See Debugger>>openOn: process context: context label: title contents: > contentsStringOrNil fullView: bool > > at 'Project spawnNewProcessIfThisIsUI: process' > > > >> Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create >> modal loops in Smalltalk code. I see a few references to such things in >> Pharo, but I'm fairly lost. Where should I start reading and/or browsing? >> >> Bill >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
