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: Bryce McKinlay <bryce at albatross dot co dot nz>
- 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 00:56:06 -0500 (EST)
- cc: java-discuss at sources dot redhat dot com
On Thu, 4 Jan 2001, Bryce McKinlay wrote:
> > Too bad Thread.stop is deprecated by Sun, and libgcj doesn't implement it
> > (contradicting the remark in Thread.java). I consider this a serious flaw in
> > Java.
> I was thinking about this recently and concluded that we should implement
> Thread.stop(). Clearly there are cases, particularly when you don't have direct
> control over all the code being run, where you need to shut down some misbehaving
> thread forcefully and interrupt() isn't good enough.
Exactly. My threads run in response to user input. I've found it
difficult to guarantee through testing that they will run in finite time
given arbitrary input. Early in development I was periodically restarting
the VM when it became unusable due to runaway threads.
So we made an educated guess that any thread that is unresponsive for 60
seconds or more isn't doing anything useful and is safe to stop().
If these threads were coded carefully we could make them responsive to
interrupt(). But I don't have control over them, in fact they aren't
even running Java but instead a scripting language based on Tcl.
Java's sandbox model makes it possible to prevent these threads from doing
anything destructive, except hogging the CPU. Without stop() you cannot
prevent DOS attacks from rogue threads. That's the Java "flaw" I alluded