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/

Tom Tromey <> writes:

> >>>>> "Jeff" == Jeff Sturm <> writes:
> Jeff> I understand your point.  I'm not arguing that Thread.stop is
> Jeff> safe.  There certainly exist applications in which I wouldn't
> Jeff> dare invoke stop() on a random thread.  In our case I accept the
> Jeff> risk because
> Using Thread.stop is usually a bad idea.  But sometimes it might make
> sense.  Some application writers have a lot of knowledge about what
> their application is doing, particularly on embedded systems.

I will point out that if you are using Thread.stop() for something, it
is probably due to an algorithmic error (ie, an infinite loop,
deadlock, etc).  I would expect that an algorithmic error that causes
a null pointer exception can be just as common, if not moreso, and
leave you in an equivalent mess.

To use this you will have to code critical data structures very
carefully, using volatile and proper assignment order to keep from
getting the structure corrupt.  As you might imagine, that's pretty
difficult to do, but in a system where the "critical" data structures
can be contained it's doable.

> If we can implement it without jumping through hoops, then it is fine
> with me.  If implementing it negatively distorts our thread
> implementation, then maybe we shouldn't implement it.
> Obviously, we would still mark it as deprecated if we do implement it.

I would recommend that you not implement Thread.stop(), simply because
that makes it too easy to use and abuse.  If I remember correctly, Sun
removed it because people were abusing it; they had only intended it
for disaster recovery, but people were using it mostly for "normal"
thread termination.  Instead, make people have to write native code or
something difficult.

I've been working on something like this for GCJ.  Implementing an
asyncronous exception with DWARF unwind exceptions poses quite a
challenge.  This makes the "negative distortion" a big problem, unless
you require sjlj exceptions (and the huge performance hit they
require) if using this feature.  With sjlj exceptions, it's not very
hard to implement.


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