myThread.interrupt() methods involves 2 real threads. As another post mentions, each real thread has a rather poor handle on it in the form of a Thread object. In this case, one such object is involved — the target thread object. So the real and fake thread thingies involved are
A) the real sender thread (thread23) — the call stack containing the method (sendInterruptMsg()) that sends the interrupt() message
C) the target thread object — myThread object.
B) the real target thread — the thread accessible by myThread object, potentially executing some blocking method.
void sendInterruptMsg(){ // runs in thread23
myThread.interrupt()
}
Note, in this case, the thread object is not a poor handle on the real thread, but a solid handle on the real thread. There are very few such useful instance methods in a thread object though, that’s why i say thread objects are a poor handle on the real threads.
Next thing to learn is the exception thrown as a result of the interrupt.
Q: Which real thread (stack) will generate and receive the exception?
A: (B), not C, since the thread object is NOT a call stack and can’t deal with exceptions.
Q: which method will throw it?
A: the interrupted method. Note all other exceptions are triggered by actions by the call stack itself — synchronous. But InterruptedException is triggered by a lightning strike — asynchronous.
Q: what methods can be interrupted this way?
A: blocking methods. Any method that can be interrupted must declare “throws InterruptedException”. Actually there are very few such methods, so they are important — static Thread.sleep, myObject.wait()…