Normally you don't want to leak resources, which may or may not involve zombies. And even if zombies are involved, reclaiming them need not require a signal handler, which was my original point.
oh ? Any call to fork() should be accompagnied by a call to wait() (or one of its cousins such as 'waitpid()'). The only question is whether that has to happen synchronously or asynchronously.
Calling 'wait()' synchronously basically means to block right after 'fork()' has been called untill the child process terminates. One technique that uses this approach is to detach the subprocess, i.e. to fork twice, and while the grand-child carries out the actual task, the child finishes immediately.
The much more frequent situation is to call it asynchronously, i.e. the call would be either executed from inside the SIGCHLD handler or somehow triggered by it (such as a semaphore, which is reentrant).
Do I miss something ?
Surely there's no need to call wait until the parent asks for the return value: In fact I'd kind of like the library to be similar to Boost.Threads - a child process is an object that can be waited upon, the library would only need to do something "fancy" like installing a signal hander, if the child object's destructor is called, without the object ever being waited upon. John.