This indeed makes things clearer. Thanks for the explanation, Artem.
I'm fine with the fix then (although I've noticed Oleg has already
pushed it...)
--
best regards,
Anthony
On 10/16/2013 05:24 PM, Artem Ananiev wrote:
On 10/16/2013 3:29 PM, Anthony Petrov wrote:
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?
EQ.detachDispatchThread() is called in two cases: when we caught
ThreadDeath or InterruptedExceptions, and when EDT is interrupted (and
the interrupted flag is not cleared). If this happens, when the current
AppContext is disposed, we simply don't care if any events are pending.
If the thread is interrupted for another reason, it will die anyway, but
the very next incoming event will re-create EDT. In this case, thread
interruption is considered an application bug.
Thanks,
Artem
--
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
