the correct statement is that stop would not stop a thread that is waiting if interrupt would also not stop it
Ehm, too many negations for me, but I think you meant the other way around? Anyway, there's really little to it: stop() and interrupt() both act similar: they attempt to break the thread's execution by throwing an exception inside the thread's current call stack. The difference is that interrupt() sets a flag on the thread which is checked by wait/sleep method and I/O and then thrown as a checked exception and stop() tries to throw an unchecked exception as early as possible and theoretically can happen at any given statement.
In a piece of software that cleans up resources using finally() and doesn't capture-and-ignore of Throwable/Error exceptions this shouldn't really matter that much and be safe.
Simon was worried about calling stop() and possibly leaving junk on disk or doing weird stuff. True, this can happen, but in the end it's what will happen anyway if a thread is busy-looped infinitely or locked: either we will try to kill it or the jvm will at the end of its execution.
I will modify the code to use a more graceful cascade of: interrupt() - wait a bit - then try to kill the thread because I still think it has advantages over just leaving the problematic thread running in the background. These disadvantages are:
- the vm will never exit from tests if the threads are non-daemon threads,
- background threads may interfere with other threads and provide noise that will not be reproducible.
These are my motivating factors for using stop() as a last resort option for threads that did go into an endless loop (or exceeded a largeish timeout time). Simon, I know you have a gut feeling that calling stop() is wrong, but you need to convince me with arguments other than just your gut feeling