Waiting for processes in C

Question

I've been reading the documentation on wait() and waitpid() and I'm still somewhat confused about how they work (I have gathered that wait(&status) is equivalent to waitpid(-1, &status, 0);). Below are some small snippets of code I'm working on. Please help me understand whether these snippets are written properly and if not then why not.

Goal 1: Reap all zombie children.

int reapedPid;
do {
    reapedPid = waitpid(-1,NULL,WNOHANG);
} while (reapedPid > 0);

What I'm trying to do here is iterate through all the children, reap the child if it's finished, let it keep going if it's not, and when I run out of children then reapedPid == -1 and the loop exits. The reason I'm confused here is that I don't see how waitpid() is supposed to know which children have already been checked and which have not. Does it do any such check? Or will this approach not work?

Goal 2: Wait for all children to finish.

int pid;
do {
    pid = wait(NULL);
} while (pid != -1);

Here I don't care what the resulting status is of the children - this should just keep waiting for every child process to finish, whether successfully or unsuccessfully, and then exit. I think this code is correct but I'm not sure.

Goal 3: Fork a child and wait for it to finish.

int pid = fork();
if (pid < 0) {
    // handle error.
}
else if (pid == 0) {
    // execute child command
}
else {
    int status;
    int waitedForPid = waitpid(pid,&status,0);
    assert(waitedForPid == pid);
}

Here I'm just trying to fork the process and have the parent wait for the child to finish. I am not entirely sure if I should be passing in the 0 option here but it seemed like WNOHANG, WUNTRACED, and WCONTINUED were not really relevant to my goal.

score 2 · Answer 1 · edited May 23 '17 at 12:12

2

For most of these, you should be able to easily code up some example programs and verify your understanding.

Goal 1: Reap all zombie children.

The reason I'm confused here is that I don't see how waitpid() is supposed to know which children have already been checked and which have not. Does it do any such check?

Once a child has exited, it can only be waited on once. So your loop will only get the exit status for child processes that have not yet been waited on (zombies).

For Goals 2 and 3, again, I would consider it a required exercise to code up an example to see how it works. For #2, I would instead suggest that your code should always keep track of all forked children, so that it can know exactly who to wait on. Your code for #3 looks good; no options are required. Remember to use the WEXITSTATUS and friends macros to get information from the status.

See also:

Waiting for all child processes before parent resumes execution UNIX

edited May 23 '17 at 12:12

Community

1
1

answered Nov 19 '13 at 03:35

Jonathon Reinhart

132,704
33
254
328

In the event that I cannot keep track of all forked children (due to certain constraints in the specifications), is #2 a viable option? – Kvass Nov 19 '13 at 03:49
@Kvass I believe so, yes. But I would code up something small and make sure. – Jonathon Reinhart Nov 19 '13 at 03:49
Ok. Also, should the assertion in my example 3 always hold true? – Kvass Nov 19 '13 at 03:53

Jonathan Leffler · Accepted Answer · 2013-11-19T04:00:18.533

It is the kernel's job to keep track of processes. Keeping track of dead processes is trivial. The kernel can tell which child processes have died but not yet been waited for, and will return one of those dead children on each call, until there are none left to report on. (Because of the WNOHANG option, there might still be children left to wait for, but none of the remaining children are dead, yet.)
This second loop is also fine and almost equivalent to the first. The difference is that it will hang waiting for all the children to die before returning the -1.
This third fragment is fine; the assertion will be true except in extraordinary circumstances (such as another thread in the program also waited for the child and collected the corpse). However, if you somewhere launched another process and let it run in the background, you might be collecting zombies, whereas with a modification of the other loops, you can collect the zombies and still wait for the correct child:
```
int pid = fork();

if (pid < 0)
{
    // handle error.
}
else if (pid == 0)
{
    // execute child command
}
else
{
    int status;
    int corpse;
    while ((corpse = waitpid(-1, &status, 0)) > 0)
        if (corpse == pid)
            break;
}
```

The loop you provided for #3 is an interesting means of multitasking. As far as #2, you said it is equivalent to #1 but I'm trying to achieve two different ends in those cases - is #2 then wrong? In the second case I want to wait for everything to finish, zombie or not. In the first I don't want to really do any stalling, just reap what I can and then move on. — Kvass, Nov 19 '13 at 03:51
You're right; I wasn't paying quite enough attention to the options in the first loop. I've updated my answer; your understanding is pretty much spot on. If you're coding a shell, you may well let users run jobs in the background (`&`?); then the loop I show becomes important — though you'd probably want to record the individual child's deaths (for example, so you can let the user know that their background jobs are done), or so you can handle the exit statuses of each command in a pipeline, or ... — Jonathan Leffler, Nov 19 '13 at 03:57

Waiting for processes in C

2 Answers2