If the child dies, the parent should receive SIGCHLD. The CHLD handler can set a global flag to restart the child before sleeping again.

Another handy way to check that a child is running is to call kill 0, $childpid or spawn_another_child();

Don't wait inside a signal handler until a child starts. That gets you nested handlers, playing dangerous games with the kernel. Instead, try something in the parent's mainline code like:

After Compline,
Zaxo

I've thought about the kill 0, $childpid solution. One of my constraints is that the code must run on several platforms (*nix not a problem, but Win32 doesn't like kill 0 much).

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?

Thanks!

...in your original question you said this:

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

I think in principle though sleep is not the right primitive. You want a wait-on-event with an additional timeout. In Win32, I'd use an Event Flag for this. I'm sure any modern OS has a selection of mechanisms like this to choose from.

How to do it portably in Perl? How about a socket? Sleeper does a blocking read on a socket, and signaler writes a byte to signal.

—John

Sounds like the socket solution might work. I mentioned below (in another reply) that the code needs to be platform independent. Is this possible with a socket? And, do you think adding socket communication would be overkill?

until ($time_to_die) {
    # listen on socket for N seconds
    # check files, client, etc
}
[download]

How about a pm module that provides for simple blocking event flags. It can contain platform-specific code for known cases, and sockets for all else. That's like File::Copy, which uses native primitives in those cases where it can, and does it itself if it must or doesn't know of a better way.

If you opt for using kill under *nix, you might substitute Win32::Event and $event->wait([$timeout]) under Win32.