java.awt.EventQueue synchronization - potential deadlock?

["Scott Gilbertson" <scottg at mantatest dot com>]

I'm trying to get the xlib peers to work with recent (feb 17) code from cvs,
and the main issue seems to be difficulty when posting an event from a
thread other than the AWT dispatch thread.  In my example program,
components are manipulated from within a timer thread, using
java.util.Timer.  The test program is essentially what's in
http://gcc.gnu.org/ml/java/2005-01/msg00064.html

With GTK, everything seems to work.  Not so with XLIB.  The timer thread
goes to do some AWT activities (setVisible, for example), which requires a
getToolkit().getSystemEventQueue().postEvent call.  The postEvent and
getNextEvent methods in EventQueue are both declared synchronized, so
postEvent blocks until getNextEvent returns something.  In the GTK case, an
event (typically PAINT) always seems to come along to save the day, but with
XLIB, the thing just sits there unless you create an event manually (cover
and uncover the window, for example).


It isn't really a new problem.  With my previous compiler (gcc (GCC) 3.5.0
20040603 (experimental)), the timer runs, but doesn't manage to paint
anything.  With the new gcc, the timer thread blocks forever unless you
create an event as above.  My big embedded application doesn't seem to
expose the problem, perhaps because I pretty much do everything in the AWT
dispatch thread.

In my opinion making getNextEvent and postEvent synchronized is problematic.
Perhaps small sections of code in each should be synchronized instead, so
that any thread can post an event while the dispatch thread is doing
getNextEvent, thus waking it up.  In particular, I think it has to be
possible to post an event while the dispatch thread is executing
iterateNativeQueue, by doing a wakeNativeQueue then taking over the AWT
event queue.

Opinions?