RFR: 8277861: Terminally deprecate Thread.stop

[David Holmes]

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.
>>
>>