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
