By installing Perl code to deal with signals, you're exposing yourself to
danger from two things. First, few system library functions are re-entrant.
If the signal interrupts while Perl is executing one function (like
malloc(3)
or printf(3)),
and your signal handler
then calls the same function again, you could get unpredictable
behavior--often, a core dump. Second, Perl isn't itself re-entrant at the
lowest levels. If the signal interrupts Perl while Perl is changing its own
internal data structures, similarly unpredictable behaviour may result.
There are two things you can do, knowing this: be paranoid or be pragmatic.
The paranoid approach is to do as little as possible in your signal
handler. Set an existing integer variable that already has a value, and
return. This doesn't help you if you're in a slow system call, which will
just restart. That means you have to die to longjump(3)
out of the handler. Even this is a little
cavalier for the true paranoiac, who avoids die in a handler because the system is out to get you. The pragmatic approach is to say
``I know the risks, but prefer the convenience'', and
to do anything you want in your signal handler, prepared to clean up core
dumps now and again.
To forbid signal handlers altogether would bars you from many interesting programs, including virtually everything in this manpage, since you could no longer even write SIGCHLD handlers. Their dodginess is expected to be addresses in the 5.005 release.
Back to Named Pipes
Forward to Using open() for IPC
Up to the perlipc manpage