<AWT Dev> Endless loop in EventDispatchThread - proposed solution

Clemens Eisserer linuxhippy at gmail.com
Mon Aug 22 11:58:32 PDT 2011

Hi Artem,

I tried to slightly change your patch. The problem with checking for
> isInterrupted() in EDT.run(), as well as for threadDeathCaught, is that the
> thread will never be marked free in AWTAutoShutdown. To fix that, we should
> make EQ.detachDispatchThread() unconditional, so it always detaches the
> thread, but this would lead to the very next postEvent() will initialize a
> new dispatch thread...

In this case we would be lucky, as EventQueue.initDispatchThread()
explicitly checks wether its AppContext is beeing disposed :)

> What if somebody calls EDT.stop() directly, without preceding interrupt()?
> I understand this is not a typical scenario, and we probably shouldn't
> support it, but we should at least not hang.

Right, if there are events left in the queue to be dispatched, it would
simply hang.

I'll prepare two patches, a less-intrusive one which simply restores the
pre-java.util.concurrent behaviour (which still will spin between
interrupt() and stop() if events are left to be dispatched), and another one
that will try to deal with the situation in a clean way, as David suggested.

I somehow believe the isInterrupted() checks were intended as "if
interrupt() has been called for this thread", instead they mean "if
interrupt() has been called, but no InterruptedException has been thrown".
Wouldn't make much sence otherwise.

Thanks, Clemens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20110822/5c354152/attachment.html 

More information about the awt-dev mailing list