Variation on a Theme: Pentuplets

Consider this next program:

This next program is largely the same as the prior one, except that each child process takes the same amount of time to complete (program is over two slides)
The code for this example can be found right here.

static const size_t kNumChildren = 5;
static size_t numChildrenDonePlaying = 0;

static void reapChild(int sig) {
  exitIf(waitpid(-1, NULL, 0) == -1, kWaitFailed,
         stderr, "waitpid failed within reapChild sighandler.\n");
  numChildrenDonePlaying++;
  sleep(1); // represents time that useful work might be done
}

int main(int argc, char *argv[]) {
  printf("Let my five children play while I take a nap.\n");
  exitIf(signal(SIGCHLD, reapChild) == SIG_ERR, kSignalFailed,
         stderr, "Failed to install SIGCHLD handler.\n");
  for (size_t kid = 1; kid <= 5; kid++) {
    pid_t pid = fork();
    exitIf(pid == -1, kForkFailed, stderr, "Child #%zu doesn't want to play.\n", kid);
    if (pid == 0) {
      sleep(3); // all kids play together for three seconds
      printf("Kid #%zu done playing... runs back to dad.\n", kid);
      return 0;
    }
  }

Variation on a Theme: Pentuplets (Continued)

Here's the second part of the program:

(This part is precisely the same as it was before).

  while (numChildrenDonePlaying < kNumChildren) {
    printf("At least one child still playing, so dad nods off.\n");
    snooze(5);
    printf("Dad wakes up! ");
  }

  printf("All children accounted for.  Good job, dad!\n");
  return 0;
}

The primary difference here is that all child processes exit, more or less, at the same time. And while it is the case that the kernel will issue five SIGCHLD signals, not all of them prompt a dedicated execution of reapChild.
Don't believe me? Check out the reproducible test run of this second version (where all five children finish playing pretty much much simultaneously).

myth22> ./indistinguishable-pentuplets
Let my five children play while I take a nap.
At least one child still playing, so dad nods off.
Kid #1 done playing... runs back to dad.
Kid #3 done playing... runs back to dad.
Kid #4 done playing... runs back to dad.
Kid #2 done playing... runs back to dad.
Kid #5 done playing... runs back to dad.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
Dad wakes up! At least one child still playing, so dad nods off.
<ctrl-c>
myth22>

Variation on a Theme (Continued)

Here's what happens:
- One of the child processes finishes before the other four, and the kernel sends a SIGCHLD signal to the parent on its behalf.
- The SIGCHLD signal is caught, and reapChild executes (over the course of one second) to handle it.
- During that one second, the second of the five child processes exits, and the corresponding SIGCHLD signal is recorded but blocked until the first call to reapChild exits. The third, fourth, and fifth child processes all exit while the first reapChild is still running, but their SIGCHLD signals are discarded, as the kernel maintains not a count of pending SIGCHLD signals, but rather a single bit that records whether one or more signals have arrived.
- When the first call to reapChild exits, the block on pending SIGCHLD signals is lifted. The kernel soon detects the high SIGCHLD bit, unaware of how many SIGCHLD signals were actually fired. reapChild is invoked to handle all the outstanding SIGCHLD signals, so that reapChild executes only one more time.
- Redux: numChildrenDonePlaying global variable is only incremented twice, and the parent process (the process modeling daddy) repeatedly takes five second naps for all of eternity.

The Solution...

... is simple, provided you understand how pending signals are recorded as bools and not counts.
- reapChild must be implemented to account for the possibility that many SIGCHLD signals were fired, not just one (e.g. that many child processes finished during the prior reapChild call, during the window when SIGCHLD signals were received but blocked).
- Each call to waitpid should include a third argument of WNOHANG, which is a flag instructing waitpid to not block on children that haven't exited yet. When WNOHANG is used, we want to break on two different return values:
  - 0, which means that there are other child processes, but that none of them have transitioned to zombie status, and
  - -1, which means what it's meant before: that there are no children (which is confirmed by the fact that errno is set to ECHILD).

The Solution

The solution makes use of WNOHANG.

Here is the correct implementation of reapChild (look here for the code).

static void reapChild(int sig) {
  pid_t pid;
  while (true) {
    pid = waitpid(-1, NULL, WNOHANG);
    if (pid <= 0) break;
    numChildrenDonePlaying++;
  }
  exitUnless(pid == 0 || errno == ECHILD, kWaitFailed,
             stderr, "waitpid failed within reapChild sighandler.\n");
  sleep(1); // represents time that useful work might be done     
}

Here's the output of the repaired program:

myth22> ./pentuplets
Let my five children play while I take a nap.
At least one child still playing, so dad nods off.
Kid #1 done playing... runs back to dad.
Kid #2 done playing... runs back to dad.
Kid #4 done playing... runs back to dad.
Kid #3 done playing... runs back to dad.
Kid #5 done playing... runs back to dad.
Dad wakes up! All children accounted for.  Good job, dad!
myth22>