This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Precise GC (was Re: cannot build libjava/gnu/gcj/xlib/

Bryce McKinlay wrote:
> 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.

Yes, but it's been proven to be almost impossible to "written defensively"
this code. And there is a lot of such code. most of libgcj for example. 
Is libgcj "written defensively" ?

> > 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 situation where it would be safe to call Thread.stop() would
be very rare. If I suspect that a thread can deadlock or busy loop,
I'd fix the thread rather then prove that I can safely call Thread.stop()
on it.
And if you don't have the source code for this thread, you cannot
assume that calling Thread.stop() will be harmless.

> The ability to interrupt IO operations is
> implemented inconsistently on different platforms.

Yes, this is a real problem, I agree.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]