This is the mail archive of the java-discuss@sources.redhat.com 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/natClip.cc)



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
to earlier.

Jeff



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