Basically, a routine is "reentrant" if you can interrupt it at any point in its execution, run it again from the interrupt (either a signal, or an interrupt handler, or another thread, although thread safety is tougher and different than reentrancy) and then resume the original execution later without problem.

The issue with Perl signal handlers, as I understand it, is that the signals are delivered to your signal sub when they are received from the OS, even if Perl is in the middle of some other operation, like a hash update, or a substitution. It's possible that the operation you've interrupted was in a non-reentrant routine at the time, so if you do anything that causes that routine to be called, you're toast.

What I understand from my (limited) reading of p5p is that signals are unsafe in all versions of perl for now. There also doesn't seem to be a consensus as to how to make them safe, so you should be very careful about how you use them. I get them impression that setting an integer scalar that already exists to a new (also integer) value is likely to work ok, most of the time. Everything else will depend.

So you may have to settle for setting some "$signaled" flag that you then check in your main loop, for instance. Far from ideal. But better than blowing up, also...

The p5p threads, BTW, also seem to say that malloc is not the only culprit, and one reason that this particular approach is not necessarily safe is that calling your signal handler involves a sub invocation, which may do non-reentrant things beyond your control.

Good luck. I recommend the perl5-porters archive. Check out <A HREF="http://www.xray.mpe.mpg.de