doubt about the interrupted() method

Hi All
I have written this code....
public class ThreadRunner extends Thread{
public void run(){
for(int i=0;i<10;i++){
System.out.println("printing");
try{
sleep(1000);
}
catch(InterruptedException iex){}
}
}
public static void main(String args[])throws Exception{
Thread t=new ThreadRunner();
t.start();
t.interrupt();
System.out.println(t.interrupted());
System.out.println(t.interrupted());
}
}

Now when I call the interrupted() method first time the value printed out should be true.But the value being returned is false.
Can anyone please explain?
Regards
sanj

Well, for a start Thread.interrupted() is a static method that always works on the current thread - your calls merely test if the main thread is interrupted, which it isn't. To do what you want to do, you'd need to use the isInterrupted() method.
But that wouldn't work either. The interrupted flag indicates that a thread has been interrupted but the interrupt still needs to be effected. It is therefore cleared as soon as an InterruptException is thrown.
The Thread.interrupted() method is especially useful if you are in a loop that doesn't wait() or sleep(), but where you would still like to act upon an interrupt:Because the call clears the flag, this doesn't work well within nested loops. One way around that is to throw your own InterruptedException and let that propagate up the call stack:In fact this is emulating what wait() and sleep() do behind the scenes.

- Peter

[This message has been edited by Peter den Haan (edited October 18, 2001).]

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.
[ February 26, 2002: Message edited by: CL Gilbert ]

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.

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.
Try it, and have a look at the comments in java.lang.Thread.
- Peter

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.
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().

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.

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.

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().

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

[This message has been edited by Peter den Haan (edited October 24, 2001).]

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

If you don't override thread.interrupt() and you are not wait()ing or sleep()ing then how will calling thread.interrupt() do anything?

Quoting from my first response in this thread:This is how you can make sections of code that don't wait() or sleep() interruptable. Note that it more or less forces proper interrupt() semantics on you: the exception propagates straight out of all the nested loops and method calls you might have, aborting everything the thread might be doing. This is, of course, entirely as it should be; should a smoother shutdown be desired, an interrupt is probably not appropriate.
- Peter
[This message has been edited by Peter den Haan (edited October 26, 2001).]

Hi Peter
I am sorry if I upset you with this post but is there any chance there might be a vacancy in your office for a Java Programmer.It would be great to learn things from a master like you.
Regards
sanj