[concurrency-interest] Does "Thread.stop" do what is says it does?

Dawid Kurzyniec 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?


BTW:

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.)

Regards,
Dawid



More information about the Concurrency-interest mailing list