Re: What is so bad aboud Thread.stop() ?
In article <v_qdnar96e1XcGbMnZ2dnUVZ7tqdnZ2d@bt.com>,
"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
taqmcg@gmail.com wrote:
I think Lew shares the apprehension I had had that it does something
magical and brings the thread down instantly, it seems clear that its
behavior is dangerous but bounded.
Can the behaviour of Thread.stop() be relied on ? For an API that has been
deprecated since the early Pleistocene, (and which -- if my very vague memory
is roughly correct -- has never been implemented correctly anyway) it seems
that implementers have the right to do practically anything. It's not as if
we
haven't been warned.
-- chris
Native thread stopping is definitely implemented in some way. It's
what's called when the JVM is quitting. What's not guaranteed is that
Thread.stop() is connected to it.
You can maybe use Thread.stop() with design patterns based on
compare-and-set. CAS is an atomic operation at the CPU level used for
non-blocking multithreading. It exactly runs or does not run, with
nothing in between. The design is essentially:
ImmutableThing originalThing, newThing;
do
{
originalThing = atomicRef.get();
if (originalThing.hasData(myChanges))
break;
newThing= new ImmutableThing (originalThing, myChanges);
} while (!atomicRef.compareAndSet(originalThing, newThing));
Of course you're still completely screwed if you happen to call
Thread.stop() while some line of code is invoking the ClassLoader or a
static initializer.