in reply to signal handling in exec()'d code

Quite unrelated: Are you sure you want to do that much in a signal handler?

sub int_handler { print "\n\n\t\t\tWe caught SIGINT; we are shutting down now...\n"; $SIG{INT} = \&int_handler; ### OTHER STUFF ### exit(1); }

The "better safe than sorry" approach towards signal handlers is to do as LESS as possible inside the signal handler and let the main program handle the situation. Remember that signals may interrupt EVERY system call. Typically, you would only set a flag inside the signal handler (e.g. $caughtSigInt=1 or just $stop=1), and check that flag inside the main loop (e.g. while (!$stop) { .... }).

Why do you setup int_handler as handler for SIGINT again inside int_handler? Is it cargo cult or intentionally? You would need that if you wanted to handle multiple SIGINTs (i.e. Ctrl-Cs) inside the same program, e.g because you want to (ab)use the SIGINT for something completely different (like updating a status line or terminating just a subroutine instead of the whole program). But if you want to exit the program, this makes no sense. Every SIGINT following the first one will effectively restart the routine.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^2: signal handling in exec()'d code
by ikegami (Patriarch) on Jan 26, 2010 at 18:02 UTC

    The "better safe than sorry" approach towards signal handlers is to do as LESS as possible inside the signal handler and let the main program handle the situation.

    That would be true if the signal handler was called from the actual signal handler Perl gives the system. This hasn't been the case since 5.8.0 (See "Safe Signals" in perl58delta.) Perl signal handlers don't even interrupt Perl opcodes, much less OS system calls.