RFR: 8277861: Terminally deprecate Thread.stop

[Alan Snyder]

>> It is almost impossible to write any non-trivial code that is async-exception-safe and no JDK library code is written to be async-exception-safe including thread tear-down. So while you can say "stop() is the only way to disrupt this piece of code", you cannot ensure that it is disrupted safely. Once stop is used you need to throw away _all_ stateful objects that may have been in active use while ThreadDeath was propagated. And even during propagation you can easily trigger secondary exceptions.

It seems that it should be possible to stop a thread spawned to execute code in a native library that works on data in native memory..
If what you say about thread tear-down is true, then I guess I would need to spawn the thread from native code as well.



> On Nov 30, 2021, at 5:58 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 1/12/2021 3:13 am, Alan Snyder wrote:
>> Although I understand the potential dangers of using Thread.stop, it seems to me there are cases where its use is legitimate and valuable.
> 
> No there really aren't. :) The perceived utility of stop() is an illusion. It is almost impossible to write any non-trivial code that is async-exception-safe and no JDK library code is written to be async-exception-safe including thread tear-down. So while you can say "stop() is the only way to disrupt this piece of code", you cannot ensure that it is disrupted safely. Once stop is used you need to throw away _all_ stateful objects that may have been in active use while ThreadDeath was propagated. And even during propagation you can easily trigger secondary exceptions.
> 
> Cheers,
> David
> 
> 
>> The examples I am thinking of involve a potentially long running computation whose result is no longer needed.
>> In particular, I am thinking of pure computations such as image analysis or audio analysis that do not involve waiting (so that interrupt is not useful)
>> and probably are implemented using some C library (which is not feasible to modify to insert code to support graceful interruption).
>> Is there some alternative that can be used in such cases?
>> Perhaps a version of stop() that only works if no locks are held?
>>   Alan
>>> On Nov 30, 2021, at 7:51 AM, Roger Riggs <rriggs at openjdk.java.net> wrote:
>>> 
>>> On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>>> 
>>>> Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998). It's time to terminally deprecate this method so it can be degraded and removed in the future.
>>>> 
>>>> This PR does not propose any changes to the JVM TI StopThread function (or the corresponding JDWP command or JDI method).
>>> 
>>> Past time for this to go.
>>> 
>>> 
>