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.
