Stef, When I saw Project was involved, I immediately though you and the other usual suspects in the "cleaning" business - you guys do great work, and it can't be easy.
FWIW, Dolphin defines ProcessorScheduler>>forkMainIfMain, and I have code that uses same, so there likely will be such a method in my image at least. Of course, I can write it in terms of anything else you might want to use, but it seems a logical choice to me. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stéphane Ducasse Sent: Sunday, August 16, 2009 4:18 AM To: [email protected] Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? Bill (and igor) I would love to continue to remove Project from the image so the "spawnProcessIfThisIsUI:self activeProcess." should probably find another host. Do you have an idea about the class that could be the natural place to define such a method? if so can you propose a change? Stef On Aug 16, 2009, at 5:57 AM, Schwab,Wilhelm K wrote: > 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. > > 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 _______________________________________________ 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
