I don't know why the Windows VM does not signal the semaphore. There are, of course, good and bad possible reasons why that might be.
The up side includes possible motives of compensating for weirdness in the Windows event queue over the many versions. Dolphin tries to be correct about it, and it took some effort; arguments could be made that they failed to get it right across all platforms (I recall having troubles with COM servers failing to run at times with the default event loop); OA dropped official support for Win2k years before that was appropriate (if it is even now), and the message queue appeared to be at the center of it. Correct me if I'm missing a combination of versions, but every time I have tried an old Squeak image and a modern vm on any old version of Windows I happened to have handy, dragging time image onto the vm worked. The bad part of waiting with a timeout is that the system runs (good) even when it is not properly managing the message queue, masking the problem (bad). As Levente suggets, one way to react to this is to ensure that the Linux and Mac vms do not need the timeout. ________________________________________ From: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] Sent: Sunday, October 17, 2010 12:17 PM To: [email protected] Subject: Re: [Pharo-project] Speeding up Pharo 1.1 On Sun, 17 Oct 2010, Henrik Johansen wrote: > > > Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <[email protected]>: > >> Btw it would be better to use the input semaphore instead of polling for >> events, like Squeak does it. I wonder why was it changed. >> >> >> Levente > It doesn't, there's effectively polling done in the UI threads hand > processing on Squeak. I see. But MessageTally doesn't: MessageTally spyAllOn: [ 10 seconds asDelay wait ] Squeak: **Leaves** 99.7% {9970ms} ProcessorScheduler class>>idleProcess Pharo: **Leaves** 89.9% {8990ms} ProcessorScheduler class>>idleProcess 10.1% {1010ms} Delay>>wait > > If it were to -only- use the semaphore, it would run into the same issue as > the non-polling fetcher made for pharo when it was properly decoupled from > the UI, namely that Windoze VMs don't even raise it. Okay, so the windows VM doesn't signal the semaphore. It could/should still be used at least on other platforms. A mixed system is also possible, because one can wait for a semaphore signal with a timeout. So for windows the timeout can be 10ms, while on other platforms 1000ms. Also waiting for 10ms, no matter how long the event processing took is a bad idea IMHO. Waiting for a total 10ms (which includes the time spent during processing the events) results in a more responsive system. Btw why doesn't the windows VM signal the semaphore? Levente > > Cheers, > Henry > _______________________________________________ > 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
