in reply to Signal handling with (implicit) fork

Of course this isn't the correct approach. You've indicated several times that you know what the correct approach is. Fixing your suspend problems would probably be even better.

You are likely to have problems if a non-masked thread in your JVM receives the SIGINT instead. This can happen if you are using a shared JVM between processes. If you completely control the environment, this is avoidable.

This is a kludge. It works, but it's a kludge.

Now if you want to avoid Java altogether, you should look at CPAN.

Updated (OT): Here's the Java code you would need to have your apps handle a Ctrl-C gracefully:

class ExampleShutdownHook { public static void main(String[] args) { // Java code to install shutdown hook: MyShutdown MyShutdown sh = new MyShutdown(); Runtime.getRuntime().addShutdownHook(sh); // Do the Joone stuff // . // . // . } } // Example shutdown hook class class MyShutdown extends Thread { public void run() { System.out.println("MyShutdown hook called"); // Dump the shutdown file // . // . // . } }

The intelligent reader will judge for himself. Without examining the facts fully and fairly, there is no way of knowing whether vox populi is really vox dei, or merely vox asinorum. -- Cyrus H. Gordon

Replies are listed 'Best First'.
Re^2: Signal handling with (implicit) fork
by polettix (Vicar) on Aug 02, 2005 at 23:11 UTC
    This is the kind of hand-slapping I was actually looking for - I somehow sensed that it was a bad application of Laziness. But there still remain some meat IMHO: if I were to call a "simpler" program, would this be the correct way to pre-mask a signal from Perl, or do exist more robust methods?

    Thank you for the precious pointers and the OT effort :)

    Flavio
    perl -ple'$_=reverse' <<<ti.xittelop@oivalf

    Don't fool yourself.