Recipe 24.3 Stopping a Thread


You need to stop a thread.


Don't use the Thread.stop( ) method; instead, use a boolean tested at the top of the main loop in the run( ) method.


While you can use the thread's stop( ) method, Sun recommends against it. That's because the method is so drastic that it can never be made to behave reliably in a program with multiple active threads. That is why, when you try to use it, the compiler will generate deprecation warnings. The recommended method is to use a boolean variable in the main loop of the run( ) method. The program in Example 24-6 prints a message endlessly until its shutDown( ) method is called; it then sets the controlling variable done to false, which terminates the loop. This causes the run( ) method to return, ending the thread. The ThreadStoppers program in the source directory for this chapter has a main program that instantiates and starts this class and then calls the shutDown( ) method.

Example 24-6.
public class StopBoolean extends Thread {     protected boolean done = false;     public void run( ) {         while (!done) {             System.out.println("StopBoolean running");             try {                 sleep(720);             } catch (InterruptedException ex) {                 // nothing to do              }         }         System.out.println("StopBoolean finished.");     }     public void shutDown( ) {         done = true;     } }

Running it looks like this:

StopBoolean running StopBoolean running StopBoolean running StopBoolean running StopBoolean running StopBoolean running StopBoolean running StopBoolean finished.

But what if your thread is blocked reading from a network connection? You then cannot check a Boolean, as the thread that is reading is asleep. This is what the stop method was designed for, but, as we've seen, it is now deprecated. Instead, you can simply close the socket. The program shown in Example 24-7 intentionally deadlocks itself by reading from a socket that you are supposed to write to, simply to demonstrate that closing the socket does in fact terminate the loop.

Example 24-7.
import*; import*; public class StopClose extends Thread {     protected Socket io;     public void run( ) {         try {             io = new Socket("localhost", 80);    // HTTP             BufferedReader is = new BufferedReader(                 new InputStreamReader(io.getInputStream( )));             System.out.println("StopClose reading");             // The following line will deadlock (intentionally), since HTTP              // enjoins the client to send a request (like "GET / HTTP/1.0")             // and a null line, before reading the response.             String line = is.readLine( );    // DEADLOCK             // Should only get out of the readLine if an interrupt             // is thrown, as a result of closing the socket.             // So we shouldn't get here, ever:             System.out.println("StopClose FINISHED!?");         } catch (IOException ex) {             System.err.println("StopClose terminating: " + ex);         }     }     public void shutDown( ) throws IOException {         if (io != null) {             // This is supposed to interrupt the waiting read.             io.close( );         }     } }

When run, it prints a message that the close is happening:

StopClose reading StopClose terminating: Resource temporarily unavailable:

"But wait," you say. "What if I want to break the wait, but not really terminate the socket?" A good question, indeed, and there is no perfect answer. You can, however, interrupt the thread that is reading; the read is interrupted by a , and you can retry the read. The file in this chapter's source code shows this.

Java Cookbook
Java Cookbook, Second Edition
ISBN: 0596007019
EAN: 2147483647
Year: 2003
Pages: 409
Authors: Ian F Darwin

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: