Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: Interrupted exception chaining Date: Tue, 25 Sep 2012 21:43:48 -0400 Organization: A noiseless patient Spider Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 26 Sep 2012 01:43:49 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="ffb8f7085759b339c1002252b48331a4"; logging-data="3902"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/sZ1brQrP9CJMnl5LxxzXj" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 In-Reply-To: Cancel-Lock: sha1:NMPCg6+KfcZO3RFOc3PdjiGzSB0= Xref: csiph.com comp.lang.java.programmer:18935 On 9/25/2012 4:26 PM, Jan Burse wrote: > Hi, > > Daniel Pitts schrieb: >> Do you really have a use-case for uninterruptableWait? Perhaps you >> should instead have a different approach to interrupting that thread. An >> interrupt is often a result of a user-action, and ignoring it will make >> users mad. It may also be the case that the interrupt was caused >> because something else failed, and waiting no longer is useful. > > Since he calls Thread.currentThread().interrupt() the next > wait() will throw an InterruptedException. "The next wait()" is a re-execution of the first wait(). It is re-called *before* Thread.currentThread().interrupt(), and will therefore *not* throw an InterruptedException until and unless some other thread calls interrupt(). > But the biggest flaw I see in the original code, is that > done=true is not called in the exception handler, so it will > not break out of the code. Actually it will inflict a new > InterruptedException by the wait() and so on. Ah! So your diagnosis above is not about the O.P.'s code at all, but about an undisclosed modification you have imagined. Fine: Feel free to debug your own imagination. (Start with the "will inflict" part, because AFAICS no such thing will happen.) > (Erics and marks code have a similar flaw, the flaw there > is that wait() is again called, so code could block) Both markspace and I pointed out that the O.P.'s code is fundamentally flawed. My rewrite solved the question as asked, while preserving the original flaw; markspace's addressed it in a slightly different way, still preserving the flaw. I think it hardly fair to blame me and markspace for the flaw we both carefully preserved (and pointed out). > Probably the code is only working, since wait()s are allowed > to be spurious. But if this is not happening the CPU will > burn, burn, burn, ... This the first time I have encountered "spurious" in the description of a *call* to wait(). It is known that a *return* from wait() may be "spurious" in the sense that it can occur without a notify() or notifyAll() or interrupt(), but in what sense can the *call* be "spurious?" -- Eric Sosman esosman@ieee-dot-org.invalid