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

[Jeff Sturm <jsturm at detroit dot appnet dot com>]

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