I have an c++ application which uses the function fork and execvp().
The parent does not wait until the child ends. The parents just creates children and let them do their stuff.
You can see the parent program as a batch-manager.
I have added a SIGCHLD handler to the program:
void zombie_handler(int iSignal)
{
signal(SIGCHLD,zombie_handler); //reset handler to catch SIGCHLD for next time;
int status;
pid_t pid;
pid = wait(&status); //After wait, child is definitely freed.
printf("pid = %d , status = %d\n", pid, status);
}
int main(int argc,char* argv[])
{
signal(SIGCHLD,zombie_handler);
...
while (condition)
{
fork();
//do child-actions & do not wait for child to finish. We can't afford to wait...
}
}
How can i avoid signal races in this case? I don't want another SIGCHLD-signal while I'm busy with processing a SIGCHLD-signal !! I don't want to ignore the signal neither when I'm processing a SIGCHLD-signal (cant afford to loose information about childs)
In the signal-handler I have added the wait() function. The time that wait will need will be none, because the child has already been terminated but is not freed yet? Am I correct?
I would like to add that signals in unix are generally not queued despite some documentation to the contrary. So if 3 children exit while the parent is not running, it is not probable that the parent will receive 3 SIGCHLD signals. So the handler should be willing to loop to reap zero or more children.
I see that Posix seems to be blessing most of the System V SIGCHLD semantics:
That's from the Posix sigaction man page. So properly ignoring the signal may be an option as well.