Summary
| ||||
| Copyright 1999 Sams Publishing |
| | ||
| | |
| Guidelines for Using SureStop |
| | |
| The stop() method on Thread has been deprecated for very good reasons (see Chapter 5, Gracefully Stopping Threads ). SureStop should only be used in conjunction with other, safer techniques for stopping a thread. If those other techniques happen to fail to get the thread to die, SureStop steps in after a timeout and abruptly stops the defiant thread. Typically, a thread will not die naturally because it is blocked on a statement that ignores interrupts. |
| | |
| For instance, the following statement makes SureStop monitor threadA for 45 seconds and abruptly stop the thread after that timeout if it hasnt died: |
| | |
| SureStop.ensureStop(threadA, 45000); |
| | |
| The ensureStop() method of SureStop is static so that it can be easily accessed from anywhere . It also very quickly adds the passed Thread reference to the list of monitored threads and returns, allowing the calling thread to continue with other tasks . SureStop has a thread running within it that occasionally checks the list of monitored threads and stops those that have reached their expiration time. |
| | |
| This tool can be very useful in long-running applications like servers that might run for weeks or months at a time. SureStop helps to make sure that the server-side threads of defunct client sessions do not continue to run indefinitely. |
| | |
| As I mentioned earlier, SureStop is a tool that should be added to your arsenal of techniques to get threads to stop running, and should not be used alone. The self-running object model can be extended to add the safety net of SureStop , like this: |
| | |
| public void stopRequest() { |
| // be sure that it is stopped within 60 secs |
| SureStop.ensureStop(internalThread, 60000); |
| noStopRequested = false; |
| internalThread.interrupt(); |
| // |
| // insert any other techniques used to get the internal |
| // thread to die normally... |
| // |
| } |
| |  | ||
| Toc | |||
