Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
This is not the issue, and it isn't true - the interrupted flag is just a bit that is being set the moment interrupt() is being called, and it can be interrogated using (static) Thread.interrupted() or Thread.isInterrupted() straightaway. The thread doesn't even have to have started running, although start() must have been called first.Originally posted by CL Gilbert:
Yes, the thread receiving the t.interrupted instruction has not had time to process it by the time your main thread is asking it if its interrupted, which at that time, it is not.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Not quite. Although the implementation is hidden in native code, I doubt they'd be polling the interrupted flag. Rather, I imagine the interrupt() method changes the thread state to "ready-to-run" if it's wait()ing or sleep()ing. Whether this bit of speculation is true or not, the comments in the java.lang.Thread code clearly indicate that an "interrupted" flag bit exists.Originally posted by CL Gilbert:
Interesting. So your implying that sleep() and wait() actually are polling this flag, and when they see it set, they
1. throw InterruptedException
2. Clear the flag.
I don't think I'd ever want to override Thread.interrupt(). But, provided that the thread's current action needs to be interrupted straightaway, I am likely use interrupt() for the purpose even if the code being executed doesn't wait() or sleep() (their presence or absence is IMHO an implementation detail that should not be exposed to other classes), polling the interrupted flag where appropriate. If, on the other hand, the thread's action should continue until it had reached some point of closure and then be diverted to do something else, this would not satisfy the semantics of an "interrupt" and (ab)using interrupt() would be a bad idea.Interesting indeed. Now I understand why you equated this function with any type of interrupting a thread action. So you would have to override the interrupt() method in your thread, and handle it as you wish, as opposed to passing it on to super.interrupt().
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
I don't think I'd ever want to override Thread.interrupt(). But, provided that the thread's current action needs to be interrupted straightaway, I am likely use interrupt() for the purpose even if the code being executed doesn't wait() or sleep() (their presence or absence is IMHO an implementation detail that should not be exposed to other classes), polling the interrupted flag where appropriate. If, on the other hand, the thread's action should continue until it had reached some point of closure and then be diverted to do something else, this would not satisfy the semantics of an "interrupt" and (ab)using interrupt() would be a bad idea.
- Peter
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Don't get me started about those stupid light bulbs. |