Godmar Back wrote:
> Hi,
>
> this is in reply to a mail by Scott Miller <[EMAIL PROTECTED]>
> from Sep 26. He wrote:
>
> > Okay, Q: suspend and resume have been deprecated in the JDK1.2b4. What do
> > you use instead of them?
>
> - Godmar
>
> Forwarded message:
> > From [EMAIL PROTECTED] Tue Jun 30 11:56:22 1998
> > Date: Tue, 30 Jun 1998 10:55:46 -0700 (PDT)
> > From: Marianne Mueller <[EMAIL PROTECTED]>
> > Reply-To: Marianne Mueller <[EMAIL PROTECTED]>
> > Subject: Re: Thread.stop/destroy
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Message-ID: <libSDtMail.199806301055.3293.mrm@shorter>
> > MIME-Version: 1.0
> > Content-Type: MULTIPART/mixed; BOUNDARY=Ostentation_of_Peacocks_679_000
> > X-Mailer: dtmail 1.1.0 CDE Version 1.1 SunOS 5.5.1 sun4u sparc
> >
> > --Ostentation_of_Peacocks_679_000
> > Content-Type: TEXT/plain; charset=us-ascii
> > Content-MD5: oPmOt/0HECT518T8B3g9Pg==
> >
> >
> > > Hi, this is a question concerning Sun's strategy in dealing with
> > > uncooperative threads. As of 1.2b3, a conformant application has no
> > > way of stopping these threads: Thread.stop() is deprecated (and wouldn't be
> > > effective anyway because ThreadDeath can be caught.) and Thread.destroy
> > > is not deprecated, but also not implemented. Both have known problems
> > > regarding damaged data structures and deadlock.
> > >
> > > So, what is Javasoft's long-term answer as to what the recommended way to
> > > kill an uncooperative thread is?
> >
> >
> > There is no way to kill an uncooperative thread, period. This
> > has nothing to do with Java. It can't be done in Java, C, or
> > other reasonably powerful languages. There's nothing JavaSoft
> > can do. Thread.stop was an unsuccessful attempt to do so.
> >
> > The JDK 1.2 Thread.stop deprecation white paper clearly stated
> > why we can't kill uncooperative threads. If anyone has ideas of
> > how to solve the technical problems, we would be interested to
> > know.
> >
> > Refer to
> > http://java.sun.com/products/jdk/1.2/docs/guide/misc/threadPrimitiveDeprecation.
> > html
> >
If you faked a excpetion wich can only be caucht by the "MASTER" Thread then you
could kill ther offending
thread. This requires some simple code genration but the Idea is the next time the
code runs you genrate and excpetion
which must be rethrown in its handler
try {
}catch( KillError e ) {
}
is translated to
try {
}catch( KillError e ) {
throw new KillError e );
}
The exception is thrown initially by and external thread into the offending
thread.
This will effictivly kill a thread IMHO.
You could even simply patch in some invalid code to cause something like this this
to happen. right after the pc counter.
If you modify the bytecode on the fly its and easy probelm.
Why just let Jits do it ? If its in a endless loop in a native funtion yes there are
problems but in java it looks easy enough to me.
Mike
