2009/8/16 Stéphane Ducasse <[email protected]>: > 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? >
IMO WorldState is the way to go. Since you removing Project, then you couldn't have multiple worlds, right? > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
