2) If 1) is 'yes', is there a way to leave the signal handler, break from the sleep(), and then attempt to restart the child, test, etc?

...I don't know any reason to believe that you're still "in the sleep()" at the time your signal handler is running. (I can't claim knowledge of this about Windows, but I do know that for Unix,) you've already been interrupted from sleep() by the time your signal handler is running.

So my expectation is that when your signal handler is running, it will complete, and your program will attempt to execute whatever follows the call to sleep() in its main flow of execution. So I don't think what you've suggested as a signal handler is too ambitious.

You also said:

I do have a abstracted method for checking the child is alive. Do you think that the sleep 1 until $child_is_dead will be to expensive on the machine?

I can't tell for sure, but I would say that each time your main thread wakes and then puts itself back to sleep, you have a context switch, wait for the main thread to be scheduled onto the CPU and (on Unix at least) it then has the clock install another alarm to wake you up one second later.

I can't really guess the impact to your system of having a one-second wake cycle on the speculative consideration that your child is dead. I would simply say this. We stress that signals are to be handled with care so that novice programmers will not go berserk trying to make everything hang off of this admittedly very crude form of IPC. And to be fair, signal handling has not always (some would say ever) been implemented very cleanly in the OS. But when a process is supposed to react to the death of a child process, that is one of the things that signals were explicitly designed to help you do.

If you can make it work (on all of your desired platforms) by installing a signal handler, then that would be better than a one-second polling loop.

But do be aware that I cannot tell how complicated your handler is or the impact in other ways to your server. So YMMV.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

You're right. I don't know what I was thinking. When control returns from the signal handler, the previously running statement is complete (even if it is a blocking statement. So, the signal handler doesn't really need to do anything, just break from the sleep(). I will need to verify this works the same on Win32, but I think this is the solution to my problem.

Thank you so much! Casey