2004-07-23

Adding SIGQUIT handlers in Java

I wanted to make my code for diagnosing VMs hung on exit more integrated with the VM. A shutdown hook is obviously useless, because the whole problem is that we're not shutting down. What's the first thing you do when your Java program is hung? You send it SIGQUIT, and see what the various threads are doing.

Ideally, you'd be able to addSigQuitHook (or addDiagnosticHook or something a bit more focused on the intention than the implementation). But you can't. And it turns out you can't use sun.misc.Signal and sun.misc.SignalHandler to add a SIGQUIT handler, because the VM doesn't allow more than one handler per signal. And it's already using SIGQUIT, as we know. SIGUSR1 is in use, too. You can have SIGUSR2, but I want SIGQUIT, damn it!

Hopefully they'll fix that at some point. One of the great leaps from the C mentality to the Java mentality was from the global variables and zero-or-one "instances" to the zero-or-many instances of Java. Where it's as cheap (in terms of programming effort) to have a vector of listeners as it is to have a single call-back function pointer. And where the standard idiom is to add listeners to a list and fire events by traversing the list.

It's a shame that potentially useful signal-handling functionality is spoiled by being in a package we're not supposed to use, and by being so limited by design. Maybe we'll get proper signal handling in 1.6; after all, we got proper environment variable support in 1.5. I'd almost given up hoping for that.