Hi Oleg,
The fix looks good to me. However, I don't recall all details about this
machinery, and removing a call to peekEvent() in
EventQueue.detachDispatchThread() looks a bit scary.
Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if
there are still events in the queue, or we simply don't care about them?
--
best regards,
Anthony
On 10/16/2013 02:31 PM, Oleg Pekhovskiy wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/2228674.1/
for
https://bugs.openjdk.java.net/browse/JDK-2228674
The fix covers two scenarios:
1. User code calls EventDispatchThread.interrupt() and then
EventDispatchThread.interrupted() which clears interrupted state and
EDT doesn't stop.
2. EventDispatchThread.interrupt() is called without clearing the
interrupted state (e.g. invocation of AppContext.dispose()) that makes
EDT terminate.
The other scenario, in which AppContext.dispose() is called from the
thread other than EDT and after that EventDispatchThread.interrupted()
is called from EDT preventing EDT from termination, is treated like an
architecture bug.
Some dead code was also removed because detaching of EDT is always forced.
Thanks,
Oleg
