From: Peter C. Mehlitz (peter@transvirtual.com)
Date: Tue Sep 08 1998 - 14:50:11 EDT
>I see a related problem in EventQueue.getNextEvent in the X11-based AWT.
>There, the thread polls for events at a given rate, which clearly seems
>suboptimal. The reason it needs to poll is because even if it could
>"fixfd" the file descriptor associated with the X11 connection, it
>couldn't get Xlib to use jsyscall's "read".
If we make getNextEvent a Java-threaded call (i.e. by using the X conn fd to
block / unblock the event dispatch thread), we don't gain anything in case of
user-threads. This would just shift the polling to some location that doesn't
know about the peculiarities of native X events. If you look at
EventQueue.getNextEvent(), you see that the polling is done in a adaptive way.
There are certain sequences (e.g. keypress..keyrelease, or
mousepress..mouserelease) where you know that it's probably a good idea to
increase the polling rate (the "AWTEvent.accelHint" is used for that purpose).
Unfortunately, respond to user input can be a matter of < 0.05 sec (humans
are very sensitive for delays of these operations - check out with a bad
mouse). If we shift the polling out of the AWT, we would loose this.
In case we have kernel threads (Toolkit.isMultiThreaded), getNextEvent of
course does no polling, and Toolkit.evtGetNextEvent() would be a blocking call
(like Win32 and others). No doubt that this is preferrable (for input response
time).
I was thinking about a mixed threading scheme for some time, were we have just a
single kernel thread doing the selects, invoking the Java-(user) threads in
case IO becomes available (thus avoiding almost all polling) - but, to be
honest, I lost that out of sight.
-- Peter
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:55 EDT