System Exit Overriding Busy Loop

Question

Hi,
Why would the following code not result in a clean JVM termination when SIGINT is sent? The JVM appears to capture the SIGINT correctly (it hits the shutdown hook), but the System.exit(-1) call cannot seem to override the busy loop and terminate the spawned thread. Is this expected behavior for the VM?
public class TestSigInt {
     public TestSigInt()
          new Thread()
               public void run()
                    while(true)
          }.start();
          Runtime.getRuntime().addShutdownHook(new Thread()
               public void run()
                    System.exit(-1);
     public static void main(String[] args)
          TestSigInt tsi = new TestSigInt();
}Thanks,
hhung

Answer 1

Is this expected behavior for the VM?Yes. See javadoc for System.exit(), that leads to to Runtime.exit():
If this method is invoked after the virtual machine has begun its shutdown sequence then if shutdown hooks are being run this method will block indefinitely
So the method blocks (and presumably does nothing, but I admit I'm making up that last bit) if called as part of a shutdown hook.
the System.exit(-1) call cannot seem to override the busy loop and terminate the spawned threadRegardless of the fact that it's called from a shutdown hook, which previous messages (and the javadoc quoted) already question, there's nothing in the API javadoc that suggests that threads are gracefully "terminated".
This situation is not different from regular situations when you want to nicely end a thread in an otherwise running Java application: the API does not provide any built-in API (except Thread.stop() and destroy() which are deprecated and which use is strongly discouraged) to stop a running thread.
See Thread.interrupt() which somehow "kindly" requests interruption of a running thread, but this requires cooperation of the target thread (whose code shoud regularly poll Thread.getCurrentThread().isInterrupted() and terminate accrodingly).
The usual recommendation to make this more explicit in the code, is that the thread's code regularly checks a business-logic specific boolean, such as:
class StoppableTask implements Runnable {
    private boolean shouldContinue = true;
    public void run() {
        while (shouldContinue) {
            // do stuff
    public void requestStop() {
        shouldContinue = false;
public void class StopperThread {
    StoppableTask target;
    public void doOtherStuff() {
        target.requestStop();
}This requires cooperation form the target thread's code as well, so this is not conceptually different from the interrupt() scheme, it just has different scope (it won't unblock IOs for example).
Note that I deliberately used Runnable as opposed to Thread, first because it is a recommend practice (but you may know that already and your example was intentionally shorter to get to the point), second to highlight that the specific-solution does not use any built-in java.lang.Thread method.
Edited by: jduprez on Dec 8, 2009 11:28 AM