Why doesn't Thread.stop work in situations where Thread.interrupt doesn't work?

Question

The official ~~Sun~~ Oracle stance on Thread.stop() is that it should not be used. Among other arguments, they write:

It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either.

But I do not understand that. If a thread is busy actively working on something (not just waiting or blocking on an external resource) and doesn't explicitly check the interrupt flag, wouldn't Thread.interrupt() do nothing while Thread.stop() will still work (throw ThreadDeath)?

`Thread.stop()` -- [bad bad coding](http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Thread.html#stop%28%29). [Indeed](http://download.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html). — Nishant, Mar 09 '11 at 10:25
I corrected the link in the question to point to the actual document containing the quote. — Stephen C, Mar 09 '11 at 11:01
@Nishant what I'm trying to do is related to [this problem](http://stackoverflow.com/questions/4544128/how-can-i-make-external-methods-interruptable). I would *welcome* any solution which doesn't rely on Thread.stop() to that question, but I can't think of any which doesn't require bytecode manipulation. This is why I'm considering Thread.stop() and I'm trying to better understand the implications of using it. — Oak, Mar 09 '11 at 12:36
alright. I was missing context. It's good if you link that question here. — Nishant, Mar 09 '11 at 12:42

Stephen C · Accepted Answer · 2011-03-09T10:53:09.210

4

But I do not understand that. If a thread is busy actively working on something (not just waiting or blocking on an external resource) and doesn't explicitly check the interrupt flag, wouldn't Thread.interrupt() do nothing while Thread.stop() will still work (throw ThreadDeath)?

I think you misunderstand the quoted text. It refers to a thread that is waiting, not a thread that is running. Specifically, it is referring to cases like the following:

When the thread is blocked in an I/O call, low-level JVM implementation issues prevent it responding to either a stop or an interrupt.
A thread that doesn't want to be stopped can catch ThreadDeath, and this is analogous to a thread that doesn't want to be interrupted simply ignoring the flag.

edited Mar 09 '11 at 10:53

answered Mar 09 '11 at 10:45

Stephen C

698,415
94
811
1,216

*A thread that doesn't want to be stopped can catch ThreadDeath, and this is analogous to a thread that doesn't want to be interrupted simply ignoring the flag.* Just need to be more aggressive w/ Thread.stop(), i.e. hitting around the catch block does the trick. There are other ugly tricks to kick a misbehaving thread in the nuts but they are out of the scope. – bestsss Mar 09 '11 at 11:46
Indeed, it is a misunderstanding on my part; thank you for clarifying that. – Oak Mar 09 '11 at 11:53

score 2 · Answer 2 · answered Mar 09 '11 at 11:42

Thread.stop is not an issue about being good or bad coding with regard to being able to bail out threads. You should not use it unless as a very last resort. It is possible to do your code and expect Thread.stop() to occur but in that case interrupt() will possible do just as fine.

The issue that stop() won't work where interrupt() doesn't (i.e. blocked on some native stuff): both stop and ineterrupt would use the same native signals to carry the call.

On POSIX, if SIGUSR2 (for instance) doesn't help the native code to bail out, it won't help either of interrupt/stop. You can think of interrupt vs stop like that: both may use OS signals. The OS signals may not be honored by the native code. However, if they are: stop() also puts a Throwable on the stack that will be propagated in the java code. On the contrary interrupt only sets a flag.

The throwable, however, may pop-up in virtually any statement, so some invariants may fail to be properly handled.

Possibly, it's partly fixable via Thread.uncaughtExceptionHandler by throwing away large states, rolling back transactions, etc... Again: not advisable.

"You can think of interrupt vs stop like that: both may use OS signals [...] stop() also puts a Throwable on the stack" - very nice wording of the low-level difference, thank you! — Oak, Mar 09 '11 at 11:54

score 0 · Answer 3 · answered Mar 09 '11 at 10:29

The main reason, as far as I understand, is that the ThreadDeath exception may be thrown anywhere, whereas the interupt flag has to be checked explicitly.

Consider this code running in a thread:

public void sellItem(Store s) {
   synchronized (s) {
       if (s.itemsAvailable > 0) {
           s.itemsAvailable--;
           s.itemsSold++;
       }
   }
}

If a ThreadDeath is thrown after s.itemsAvailable--, the Store object is left in an inconsistent state. On the other hand, this code is safe:

public void sellLoop(Store s) {
    while (!Thread.interrupted())
       sellItem(s);
}

Source: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html#stop%28%29

They say that Thread.stop() would not work because (I guess) the throwable can be caught and ignored.

score -1 · Answer 4 · answered Mar 09 '11 at 10:23

-1

if the JVM is too busy to interrupt the thread, it's also too busy to kill it.

answered Mar 09 '11 at 10:23

jwenting

5,505
2
25
30

That's wrong. On a multicore machine there may be a single Thread running in a loop which can't be interrupted simply since it doesn't no operation checking for it. – maaartinus Mar 09 '11 at 10:45

Why doesn't Thread.stop work in situations where Thread.interrupt doesn't work?

4 Answers4

Linked