On Jun 22, 2004, at 4:31 PM, Stefan Seefeld wrote:
Gregory Colvin wrote:
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()
On systems that have fork().
should be accompagnied by a call to wait() (or one of its cousins such as 'waitpid()').
On systems that have wait().
The only question is whether that has to happen synchronously or asynchronously.
And that question could be answered by the process library, or left to the user.
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.
Which won't work if the parent cares about the child's exit() value?
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).
Which was the implementation Angus first suggested, which a few of us pointed out was unsafe as written. I meant to suggest the choice could be left to the user. You can also avoid blocking with a separate thread to do the wait(), or by calling waitpid() with WNOHANG in a polling loop.
Do I miss something ?
No, I think we agree on what the possibilities are for Posix.