>> 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.hol...@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 <rri...@openjdk.java.net> wrote: >>> >>> On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman <al...@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. >>> >>> >
