This is the mail archive of the
mailing list for the Java project.
Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- To: Cedric Berger <cedric at wireless-networks dot com>
- Subject: Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/natClip.cc)
- From: Jeff Sturm <jsturm at detroit dot appnet dot com>
- Date: Thu, 4 Jan 2001 01:21:07 -0500 (EST)
- cc: Bryce McKinlay <bryce at albatross dot co dot nz>, java-discuss at sources dot redhat 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
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.