[concurrency-interest] Does "Thread.stop" do what is says it does?
dawidk at mathcs.emory.edu
Thu Aug 4 13:45:37 EDT 2005
The javadoc of Thread.stop says:
* It is permitted to stop a thread that has not yet been started.
* If the thread is eventually started, it immediately terminates.
However, the first statement of Thread.stop is:
if (!this.isAlive()) return;
And isAlive javadoc says:
* Tests if this thread is alive. A thread is alive if it has
* been started and has not yet died.
This seems to imply that stop is a no-op on a thread that has not yet
started, and I can't see why the thread would be terminated as soon as
it starts. So what's the deal here?
I know that Thread.stop is deprecated and pure evil, I realize the risks
of getting inconsistent data by abruptly releasing locks, but I think
that in the system I am writing, using Thread.stop is necessary and the
risks are manageable. I am developing a multi-user middleware platform
(a distributed service container) which runs potentially untrusted code
in isolated sandboxes. Sometimes, though, "friend" services are allowed
to break the isolation barriers and share data, so the "Isolates" API is
not applicable. Instead, we implement sandboxing via separate class
loaders, strict confinement, and security policies.
For the sake of this discussion, let's assume that I am implementing an
applet container that can host multiple applets at a time. Let's say I
loaded an applet that became unresponsive and I want to unload it
anyway. I first ask it nicely to leave, wait a while, then interrupt all
its threads, wait a while, then stop all threads, wait a while, then
finally blacklist all remaining threads, set their priorities to minimum
and revoke all their security privileges. Stopping seems to be fairly
safe, since those applets don't really share any objects, so whatever
gets messed up as a result of abrupt stopping becomes a garbage anyway.
And, even if they somehow manage to lock a shared system object (which
is generally prevented by security policies, e.g. they cannot write to
standard output), the system is at a deadlock anyway if I don't stop
those bastards :)
Sure, really evil services can escape the axe by catching ThreadDeath.
Little I can do about that. But here I am trying to guard against poorly
written or buggy ones (e.g. looping infinitely, in which case merely
interrupting them won't suffice) rather than malicious ones. (The latter
case is dealt with using code source certificates etc.)
More information about the Concurrency-interest