<AWT Dev> [8] Review request for 2228674: Fix failed for CR 7162144

[Artem Ananiev]

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