From: Godmar Back (gback@cs.utah.edu)
Date: Tue Sep 08 1998 - 18:59:26 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,
the jthread system does not do polling. It uses SIGIO.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:55 EDT