Mutable Objects and Thread Boundaries
in [Java Programming]
|
Prev: Const correctness (was Re: Oppinion on 'least priviledge', 'const correctness', etc.)
Next: Simple Hack To Get $2500 To Your PayPal Account.
From: ClassCastException on 23 Jul 2010 23:50 On Thu, 22 Jul 2010 11:05:50 -0700, Daniel Pitts wrote: > On 7/21/2010 5:50 PM, Lew wrote: >> Daniel Pitts wrote: >>> I think you've misinterpreted something. There are possible spurious >>> wake-ups, but there are *not* spurious interrupts. Object.wait(...) >>> may >> >> You're absolutely right - my mistake. >> >>> *return* before the conditions are met, but will not through >>> InterruptedException unless there is a true interrupt. >> >> The fact remains that 'InterruptedException' is not about SIGINT or >> other OS signals but about response to an 'interrupted' condition. >> >> JCIP claims that there are two possible correct responses to receiving >> an 'InterruptedException' - re-interrupt the thread itself (p. 142): "- >> Propagate the exception... >> "- Restore the interruption status ..." > Actually, thats on page 93. > > Page 143 does state: > "Only code that implements a thread's interruption policy may swallow an > interruption request." > > So there are three possible responses: > 1. Propagate the exception > 2. Restore the interruption status. > 3. Swallow the interrupt, but *only* if your code is part of the > thread lifecycle management. So, the original advice of either propagate the exception or restore the interruption status was aimed at library authors writing methods that might have to handle InterruptedException but that aren't supposed to know about (or care about, or interfere with) the caller's management of threads.
From: ClassCastException on 23 Jul 2010 23:53 On Thu, 22 Jul 2010 21:26:15 -0400, Lew wrote: > Lew wrote: >>> JCIP claims that there are two possible correct responses to receiving >>> an 'InterruptedException' - re-interrupt the thread itself (p. 142): >>> "- Propagate the exception... >>> "- Restore the interruption status ..." > > Daniel Pitts wrote: >> Actually, thats on page 93. > > That's funny, actually I quoted it from the passage in the book that > actually I had open to p. 142 as I actually typed. Actually. Probably there's more than one version of it out there, and the page numbers aren't the same from one to the next. That frequently happens with the paperback vs. the hardback version of a book, and also happens when technical-topic books are republished with updates or addenda every few years. Besides the updates moving everything that comes after them, they may retypeset everything and change the style and the like, which will move things around. That said, a shift from page 93 to page 142 is large, nearly 50 pages. Either the 142 is from a paperback with 2/3 as much on each page as the hardback, or they significantly added material or rearranged sections in a revision at some point.
From: markspace on 24 Jul 2010 00:39
ClassCastException wrote: > So, the original advice of either propagate the exception or restore the > interruption status was aimed at library authors writing methods that > might have to handle InterruptedException but that aren't supposed to > know about (or care about, or interfere with) the caller's management of > threads. This is exactly correct. He says, "For library code, there are basically two choices[:] propagate the exception [or] ...restore the interrupt" He does go on to say even there (p. 93) that it is ok to catch and ignore the exception if you are implementing code that is highest up the call stack in a Thread. BTW, the difference in page numbers is because Goetz talks about interrupts in (at least) two places. Once in chapter 5, where he discusses various synchronizers like deques and blocking queues (some of which throw InterruptedException). And then again in chapter 7, including p. 143, where he explicitly talks about cancellation of a task. |