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
