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
