how is calling stop() method on this ensuring that the currently running thread of execution stops? what i mean is lets say repaint()method is already invoked. while repaint() method is executing , if i call sstop() according to me nothing will happen. repaint method will still complete execution. the above code ensures that the next time when this thread is picked up for execution, it will check for the stop flag.
I think the code is a little bit incomplete, but assuming that I'm right about what you didn't post...
Yes, your understanding is mostly correct. The "stop" method will not stop the thread instantly, it will just cause the thread to end when it's ready to end. However this part:
the above code ensures that the next time when this thread is picked up for execution, it will check for the stop flag.
I don't think that's correct. Although it really depends on what you mean by "picked up for execution". The Thread you've posted there runs an infinite loop which alternates between sleeping, repainting, and checking whether "stop" has been called. So after you call its "stop" method, it might still sleep for a while. It might repaint again after that. But then it will notice that the condition for the while-loop is no longer true, and it will exit from the "run" method. This causes the Thread to end.
posted 5 years ago
thank you paul.
lets suppose i tweak the requirement a bit. lets say my run() method needs to call repaint() only once. in such a case, how do i stop a thread from completing the repaint() method
You don't. If you want the repaint() method to be interruptible, you have to write it that way. It just isn't possible for Java to interrupt arbitrary code and have it return from a method, abnormally or otherwise.
posted 5 years ago
It just isn't possible for Java to interrupt arbitrary code and have it return from a method, abnormally or otherwise.
I was thinking the same way, but numerous google searches on the internet on the same topic made me think that it might be possible. Thank you for the clarification, Paul
In the original Java, it was possible for an external source (another thread) to forcibly stop a thread.
This was determined to be a bad idea, since a thread could be halted while in the middle of a sensitive operation, while holding locks (synchronized code), and/or while holding resources that needed to be properly freed.
So support for that type of operation was withdrawn in favor of a convention where a thread would check for external notification that it should halt itself (after first properly cleaning up).
Even full-blown operating systems, which often have extensive built-in resource management, termination and recovery facilities have occasional problems with thread/process breakage, as can be seen with the Linux "Zombie" process status, so Java avoided all the complications by insisting on use of a simpler model.
An IDE is no substitute for an Intelligent Developer.
The idea here is just that the thread runs its due course. The best method of being able to stop/interrupt a thread, is writing your code to check whether it is allowed to continue before it continues.
So if you're writing code where you need to call a Thread's API to interrupt or stop it, you're going about it the wrong way.