Hi David,<br><br>Thanks for your feedback.<br><br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">You changed from Lock to ReentrantLock so that you could use isHeldByCurrentThread(), but that locks in (pardon the pun) the kind of Lock that AppContext must use.<br>

You should add a comment explaining why the check for isHeldByCurrentThread is needed - and that if things are done right at a higher-level we should never need the stop() to break out of await().<br></blockquote><div class="gmail_quote">
<div><br>I will add a comment about that, I also took the lock-in to ReentrantLock as a trade-of as I couldn&#39;t think of another lock-implementation that would be more suitable for the job of the pushpopLock.<br>I think things are done the right-way at a higher level (as with the &quot;full&quot; patch, the code should *never* catch ThreadDeath execpt some user-code in an InvocationEvent does strange things - which we can&#39;t control).<br>
Also the &quot;normal&quot; way of termination doesn&#39;t depend on catching ThreadDeath or InterruptedException, as shutdown is set synchronously to true by the Thread calling AppContext.dispose().<br><br>What bothers me is that code known to be good style and is recommended everywhere, simply hides an InterruptedException and causes an IllegalMontorState-Exception to be thrown - actually the isHeldByCurrentThread is just there to avoid ugly IllegalMonitorException Stack-Traces printed out - as its done when using ThreadPools with Applets. Java&#39;s monitor design took care of that. As far as I can see, a tryUnlock() method would solve those problems.<br>
<br><br>¬†<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Overall I&#39;m still concerned that there is an issue in the overall design that permits events to be queued even after a &quot;shutdown&quot; has been logically initiated. With this patch those events won&#39;t get processed and not knowing what they are I can&#39;t say whether this will be a problem or not. It is a concern that the current code in detachDispatchThread says:<br>

as it seems to indicate that the exact conditions for detachment are unclear. Based on reading 4648733 I&#39;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.<br>
</blockquote><div><br>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 events (I don&#39;t think the isInterrupted() call was really ment that way).<br>
However, I wonder why AppContext.stopEventDispatchThreads() is never used in AppContext.dispose(), as it seems to provide a cleaner way for shutdown?<br><br>Thanks, Clemens<br>¬†</div></div>