Re: What is so bad aboud Thread.stop() ?
On 8/14/2013 8:55 AM, taqmcg@gmail.com wrote:
The cooperative Thread.interrupt() approach implies that the code
that might be interrupted knows about this, i.e., the worker code is
aware that there is some monitor. It needs to periodically check
the interrupt flag and do something. This couples the invoker to the
invoked in a way that's a bit unattractive.
Several low level APIs in Java check for the interrupt flag, so if your
library is calling these methods, it will check for interrupts implicitly.
Object.wait(), Thread.sleep(), most of the IO library, probably some
more which I don't recall at the moment.
Also, if you're going to be dealing with threads at all, get yourself a
copy of Java Concurrency in Practice. It's *the* state of the art for
working with threads in Java.
I'll also link to this article by its author:
<http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html>
I found your code a little baroque, so I wrote what I think is a simpler
example. Notice I never actually check the interrupt flag, but the code
terminates fine. If you comment out the call to interrupt(), then the
program does not terminate.
package quicktest;
/**
* @author Brenden Towey
*/
public class ThreadInterrupt
{
public static void main( String[] args ) throws Exception
{
Thread t = new Thread( new Wait() );
t.start();
Thread.sleep( 50 ); // wait a bit
t.interrupt();
t.join();
System.out.println( "Done!" );
}
private static class Wait implements Runnable {
@Override public synchronized void run() {
try { wait(); }
catch ( InterruptedException ex ) {}
}
}
}
OTOH hand if your library never makes any calls that do check for the
interrupt flag, well I'm pretty sure there's no chance of this working.
I'd still really prefer you find a way to make it work though; you're
spending a lot of time here to implement something that is fundamentally
broken (i.e., Thread.stop()).