Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)

Wed Jan 3 21:19:00 GMT 2001

On Wed, 3 Jan 2001, Cedric Berger wrote:
> stop() doesn't give you any benefit over interrupt() because 
> 1) a bad thread can catch a ThreadDeath exception the same way 
> it can catch an InterruptedException.

That's true of malicious threads, yes.
> 2) stopping a thread asynchronously is almost certain to corrupt 
> the state of your system.

It really depends what the thread is doing. But the situation is not
really different than e.g. a SecurityException or ClassCastException,
which are almost never caught explicitly. Arguably these are a
consequence of coding errors and should seldom occur with tested code.
Ditto for infinite loops that I would like to stop(). In fact we do use
Thread.stop() far more often during development than after a site is
released.
Similarly, we rely extensively on dynamic class reloading during
development though we almost never use it on a production system. It
simply has too many bizarre side effects when objects from different
classloaders are allowed to interact. This is strictly a
pragmatic issue for us. A feature that is regarded as "unsafe" is only
useless if safety is important!
> If you have a misbehaving thread you want to shutdown, you want to:
> 1) be nice and start with thread.interrupt() and wait a little bit

That's the first thing we try.
> 2) alter the SecurityManager to deny *all* requests for this
> thread and at the same time set its priority to the lowest value.
> This should limit damages and shut down most of the threads.

Did you know that thread priorities are nonfunctional on many VMs?
> 3) If none of the above works, call Thread.destroy() which is 
> not deprecated.

Ouch. Surely that is less safe than Thread.stop(). It's also not
currently implemented in Sun's VM. If it were, it could deadlock the
entire process, which is a disaster for us.
Jeff