From: Godmar Back (gback@cs.utah.edu)
Date: Mon Jan 04 1999 - 19:04:45 EST
>
> On Mon, 04 Jan 1999, Godmar Back wrote:
> >Peter and I had discussed how to avoid polling in the awt, but this
> >is the first time I look at his code. Judging from the comments in
> >the code, there seem to be some problems with approach.
> >I would strongly suspect that the problem comes from the fact that
> >the transport routines in Xlib cannot deal with a non-blocking fd.
>
> That's right. You have to make sure that blocking does only happens in
> nextEvent(), e.g. because you have to give up the Toolkit lock (or you end up
> in deadlocks). If the blocking is deterministic (e.g. with some round-trips),
> that's Ok, but otherwise it is a nogo. But I think I figured out all
> relevant Xlib calls, and haven't experienced any problems for quite a while
> (even though this might vary between different Xlibs / servers). Xlib really
> isn't multi-threaded at its heart, but I think we qualify for one of the first
> really multi-threaded X-apps (w/o any polling). The impacts can be rather
> dramatic, I once got a speed improvement for the CaffeineMark Dialog test
> (which is rather strange because it doesn't reflect real AWT app structure) of
> a factor of >20 compared to the JDK.
>
> Edouard - thanks for the List / PopupWindow hints, will take that in, too. It's
> getting high time for a new update.
>
Btw, if you prefer, we could also implement that a condition variable
is signaled whenever a fd becomes ready. Then you could leave the
toolkit monitor atomically.
Then all you had to do would be to wait on the condition variable.
This would even allow for multiple threads picking up events
(although I don't know whether that's needed).
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:29 EDT