<AWT Dev> Endless loop in EventDispatchThread - proposed solution
artem.ananiev at oracle.com
Fri Aug 26 05:51:44 PDT 2011
Hi, David, Clemens,
On 8/26/2011 2:02 AM, David Holmes wrote:
> On 26/08/2011 2:39 AM, Clemens Eisserer wrote:
>> Overall I'm still concerned that there is an issue in the overall design
>> that permits events to be queued even after a "shutdown" has been
>> logically initiated. With this patch those events won't get processed
>> and not knowing what they are I can't say whether this will be a problem
>> or not. It is a concern that the current code in detachDispatchThread
>> as it seems to indicate that the exact conditions for detachment are
>> unclear. Based on reading 4648733 I'm assuming that we have to keep the
>> event queue receiving events so that the shutdown event can be posted
>> (as part of AWT auto-shutdown), and that then allows other events in.
>> The question remains as to whether those events should be processed even
>> when shutdown has been initiated.
If the event dispatch thread is interrupted, it's unlikely that AWT
auto-shutdown event is in the queue and should be handled, but even if
it is, I don't see any problem here: the thread will terminate
>> I am no AWT expert, but from how I interpret the old code, as soon as
>> interrupt() has been called, it was not intended to dispatch further
>> (I don't think the isInterrupted() call was really ment that way).
I'm considered an AWT expert, but the code was introduced before I
joined the AWT team :) Oleg (in CC) may shed some light here, but
honestly I doubt the event dispatching and auto-shutdown code was
written with a clear understanding how we should react to interrupt() calls.
If we consider this change for JDK8, which is in the very beginning of
its development, I would vote for discarding all the enqueued events
when interrupt() or stop() is called.
>> However, I wonder why AppContext.stopEventDispatchThreads() is never
>> used in
>> AppContext.dispose(), as it seems to provide a cleaner way for shutdown?
Yes, it sounds like a good idea. However, we can't rely upon this this
mechanism only: the thread may be busy running user code, and the
shutdown event may be not handled, so threadGroup.stop() should still be
called from AppContext.dispose().
> I'm no AWT expert either, it just concerns me when there is an
> introduced change in behaviour without a full understanding of the
> implications. We really need some input from an AWT event processing guru.
>> Thanks, Clemens
More information about the awt-dev