 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2006Thread.interrupt() and blocking operations
In general, if a thread's interrupt status has been set, will a call to a blocking method produce the same behavior as would occur if the thread were interrupted during the blocking call? The JavaDocs seem to indicate that this is not true - for example, wait() is documented to throw an InterruptedException if the thread is interrupted before or during the call, but Thread.sleep()'s documentation is silent on what, if anything, occurs if the thread has been interrupted prior to the call to sleep(). The same also seems to be true of the select() methods of Selector. Assuming that select() does, in fact, block even if the current thread's interrupt status is set, is there any alternative to simply checking Thread.interrupted() prior to calling select() and taking appropriate action (i.e., throwing an InterruptedException manually)?  SignatureChristopher Benson-Manica | I *should* know what I'm talking about - if I ataru(at)cyberspace.org | don't, I need to know. Flames welcome. > In general, if a thread's interrupt status has been set, will a call > to a blocking method produce the same behavior as would occur if the [quoted text clipped - 4 lines] > what, if anything, occurs if the thread has been interrupted prior to > the call to sleep(). Thread.sleep() with throw an InterruptedException if the interrupt method has been called prior or during a sleep. The same also seems to be true of the select() > methods of Selector. Assuming that select() does, in fact, block even > if the current thread's interrupt status is set, is there any > alternative to simply checking Thread.interrupted() prior to calling > select() and taking appropriate action (i.e., throwing an > InterruptedException manually)? I don't know about Selectors as I have not used them but here is what the docs say about Selectors: "If this thread is blocked in a Selector then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's wakeup method were invoked." Thread.sleep(), Thread.join() and Object.wait() will all throw InterruptedExceptions if their threads are interrupted. In all other cases the interrupt status of the thread is set so that you can detect it with Thread.isInterrupted() or Thread.interrupted(). Note the difference between the two, interrupted() clears the interrupt status while isInterrupted() doesn't. SignatureKnute Johnson email s/nospam/knute/ > "If this thread is blocked in a Selector then the thread's interrupt > status will be set and it will return immediately from the selection > operation, possibly with a non-zero value, just as if the selector's > wakeup method were invoked." Yes, I've read that, but it only incompletely answers my question. > Thread.sleep(), Thread.join() and Object.wait() will all throw > InterruptedExceptions if their threads are interrupted. I know about Object.wait(), because the docs say so. Can you point me to a a reference (possibly in the documentation) that says the same thing about Thread.sleep()? Also of immediate interest to me is how blocking operations on Channels respond when the current thread has already been interrrupted; sadly, again I have no evidence from the documentation that they handle the situation intelligently. > In all other cases the interrupt status of the thread is set so that you > can detect it with Thread.isInterrupted() or Thread.interrupted(). Note > the difference between the two, interrupted() clears the interrupt > status while isInterrupted() doesn't. Yes, that's what I'm doing, but it seems silly to have to do so in light of the fact that Object.wait() is smart enough to handle the situation. SignatureChristopher Benson-Manica | I *should* know what I'm talking about - if I ataru(at)cyberspace.org | don't, I need to know. Flames welcome. >> "If this thread is blocked in a Selector then the thread's interrupt >> status will be set and it will return immediately from the selection >> operation, possibly with a non-zero value, just as if the selector's >> wakeup method were invoked." > > Yes, I've read that, but it only incompletely answers my question. I've really not played with Selectors so I can't help you with those. >> Thread.sleep(), Thread.join() and Object.wait() will all throw >> InterruptedExceptions if their threads are interrupted. [quoted text clipped - 5 lines] > already been interrrupted; sadly, again I have no evidence from the > documentation that they handle the situation intelligently. Look at Thread.interrupt(). The last line is really the most important one "If none of the previous conditions hold then this thread's interrupt status will be set." If it is not blocked on sleep(), wait() or join() it will set the interrupt status. When it encounters a sleep(), wait() or join() it will then throw an InterruptedException. >> In all other cases the interrupt status of the thread is set so that you >> can detect it with Thread.isInterrupted() or Thread.interrupted(). Note [quoted text clipped - 4 lines] > light of the fact that Object.wait() is smart enough to handle the > situation. If you need to detect it before it reaches one of the interruptible methods you will have to test for it. I don't see where this is silly. You call interrupt, it sets a flag, you test for it, I don't know how else you would do it. SignatureKnute Johnson email s/nospam/knute/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.