RFR: 8277861: Terminally deprecate Thread.stop

Alan Snyder javalists at cbfiddle.com
Tue Nov 30 20:50:59 UTC 2021


I think you are saying that to kill a thread running native code I would need to use native code. Is that right?

> On Nov 30, 2021, at 10:17 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 30/11/2021 17:13, 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.
>> 
>> 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).
>> 
> 
> JCiP Ch.7 has some good advice on this topic. In general, it needs the task to poll a cancel status or test Thread.currentThread().isInterrupted() to check for interrupt. In your scenario, with image analysis in native code, then Thread.stop won't help as it would need to return from the native code to detect the async exception.
> 
> -Alan
> 



More information about the core-libs-dev mailing list