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

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Cedric Berger wrote:

> 2) stopping a thread asynchronously is almost certain to corrupt
>  the state of your system.

It is likely to leave shared objects in an inconsistent (ie unusable) state, but this
is not the same thing as "corrupting the state of your system". If you're using thread
stop then obviously any code that communicates with the stopped thread needs to be
written defensively to account for this possibility.

> 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
> 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.
>
> 3) If none of the above works, call Thread.destroy() which is
>   not deprecated.
>
> Bottom line: Thread.stop() is useless and dangerous.

It is dangerous, but I disagree that it is useless. I agree that interrupt() should be
tried first, but it can only work for a relatively well behaved thread. It can't be
used to stop a thread that is deadlocked on a synchronize{}, or stuck in a busy loop
and not making any interruptable calls. The ability to interrupt IO operations is
implemented inconsistently on different platforms.

Thread.destroy() has never been implemented in any Sun VM, afaik, and would be even
more dangerous than stop() if it was.

regards

  [ bryce ]