The Thread method stop() doesn't appear to do anything on the Solaris/green-threads
port (it works correctly on the Win32 port).

To test this, run an applet in the AppletViewer with the -debug option (to run jdb),
and enter the "run" command. After the applet is displayed, enter "threads" to list
the threads currently running. Try using the "kill" command on one of the threads,
wait a moment, then list the threads again. The thread is still alive, usually in a
"cond. waiting" state.

The debugger needs to be able to kill threads, both to support the "kill" command,
and also to be able to restart a debugging session.

Comments by Steve Soule, 6/18/96: I doubt this bug has been fixed. Apparently threads killed with stop() don't actually die until they complete whatever they're working on--sleeping, waiting for I/O, etc. Here's a test example with sleeping:

public class StopTest
extends Thread
{
public static void main(String args[])
{
StopTest t = new StopTest();
t.start();
try {Thread.sleep(5000);}
catch (InterruptedException e)
{System.err.println("Main thread interrupted!");}
t.stop();
System.err.println("Main thread done.");
}
public void run()
{
try {Thread.sleep(15000);}
catch (InterruptedException e)
{System.err.println("Test thread interrupted.");}
catch (ThreadDeath e)
{
System.err.println("Test thread killed.");
throw e;
}
System.err.println("Test thread done.");
}
}

This program should wait 5 seconds, then print "Main thread done." and "Test thread killed." immediately in either order. Instead, it waits 5 seconds, prints "Main thread done.", then waits 10 seconds, and prints "Test thread killed."

Version 1.0.2 of the language spec, page 524, says in the description of stop(), "This thread is forced to complete abnormally whatever it was doing and to throw a ThreadDeath object as an exception. For this purpose, this thread is resumed if it had been suspended, and is awakened if it had been asleep."

I've seen the same problem when the thread being killed is waiting on I/O, as well.