On Sun, 17 Oct 2010, Henrik Johansen wrote:
Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves@elte.hu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project