From: Godmar Back (gback@cs.utah.edu)
Date: Tue Sep 08 1998 - 19:13:52 EDT
To elaborate on my previous comment:
Basically, if we could get X to use jthread's "read()" when it
tries to read the next event --- which could be done by somehow telling
Xlib where to read from --- you could turn Toolkit.isMultiThreaded on,
as that is the same behavior you get from kernel threads.
In the case of internal threads, there is also no polling done.
The internal thread system only polls for I/O if *no* thread in the system
is runnable (see when checkEvents is called). This is just plain broken.
- Godmar
>
> >
> > >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.
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:55 EDT