will continue to be supported for some amount of time into the future, you could continue to use it.
Don't.
Don't Call stop()
So what was the problem with the stop() method? Why has it been deprecated in JDK 1.2?
Basically, it has proven just too difficult to use correctly. Just like POSIX's asynchronous
cancellation, stop() will interrupt a thread in the middle of whatever it's doing and leave no
options for proper recovery of system state.
Yes, you can write a finally section to reestablish invariants, but you need to know which
invariants to reestablish (perhaps your code is complex and only half of it ran). You also have to
deal with the fact that the stop message can arrive in the middle of the finally section, in which
case that will be stopped. In other words, finally sections don't help.
About the only thing you can do is to write a stop protocol (similar to Code Example 9-6) yourself
in which the killer thread and the target threads agree on exactly when a stop request may be
issued. Basically, you would write a new class of threads StoppableThread, which would
have two new methods: enableStop() and disableStop(). You would then write a method,
myStop(), which would check the stoppable state of the target thread and call stop() only if it
were enabled. All threads that you intend to stop would have to be of class StoppableThread.
(We show this technique for interruption in InterruptibleThread.)
So it's possible to use stop() for cancellation. It's just very difficult and you probably don't want
to do this. (And of course, it's deprecated in JDK 1.2.) On top of all that, there is no clear
statement of exactly when a thread that has been stopped will actually exit. If it's sleeping, will it
be awakened? Maybe. Can it be forced to pop out of a JNI call? Maybe.
ThreadDeath
The way stop() works is that it throws an unchecked runtime exception, ThreadDeath. This
exception then propagates up the call stack, running all finally sections and unlocking all locks
that it encounters. When it gets to the initial run() method, it pops out of that, too, and the thread
exits.
When Java was being designed, ThreadDeath was not supposed to be an exposed interface; you
weren't supposed to know about it. But it did become public and is now officially supported.
That's very interesting, but now forget it.
It is possible for you to throw ThreadDeath yourself. It is possible for you to catch
ThreadDeath and deal with it yourself. You will even find topics that give you snippets of code
that do so. But they never give you enough to create a robust program. Yes, it is possible to use
ThreadDeath. Don't do that.
Using stop() to Implement Thread.exit()
There is a second use for stop(). You can use it as the Java equivalent to pthread_exit()
(Code Example 9-3). This use of stop() does not have any deadlock or data corruption problems
noted above because you call it synchronously and you can ensure that it is called only when
everything is consistent and safe. Unfortunately, even this use of stop() is deprecated. What to
do?
Example 9-3 Implementing exit()
Search WWH :
