• Assignment 2 due tonight at 11:59pm.
  • We expect to crank on Assignment 2 submissions starting on Saturday morning (after the hard deadline has passed) and send out grade reports by next Saturday.
  • In general, we promise to get grade reports back 7 days after the hard deadline.
• Assignment 3 goes out later tonight and falls due a week from Monday, on October 23^rd.
  • Assigment 3 is the longest of the quarter, and that's why you have such a long time to complete it. Please start soon.

• Finish reading B&O Chapter 2 (Chapter 10 of full textbook) so you can confirm that you know most of the material there, as I covered much of it during the first two weeks of lecture.
• Finish reading B&O Chapter 1 (Chapter 8 of the full textbook), focusing on Section 5, which covers process groups, signals, and signal handlers, all three of which will contribute to your Assignment 3 submission.

• Last time I was just about to start up on this, but didn't quite get there. Our discussion of the subprocess function relies on the notion of a pipe, the pipe and dup2 system calls, and how they can be used to foster more sophisticated communication between multiple processes.
• Once we work through subprocess, we'll start up on signals and signal handlers.

• A signal is a small message that notifies a process that an event of some type occurred. Signals are often sent by the kernel, but they can be sent from other processes as well.
• A signal handler is a function that executes in response to the arrival and consumption of a signal.
• You're already familiar with some signals, even if you've not referred to them by that name before:
  • You haven't really programmed in C before unless you've dereferenced a NULL pointer. When that happens, the kernel delivers a signal of type SIGSEGV, informally known as a segmentation fault (or a SEGmentation Violation, or SIGSEGV for short). Unless you install a custom signal handler to manage the signal differently, a SIGSEGV terminates the program and generates a core dump.
  • Whenever a process commits an integer-divide-by-zero (and, in some cases, a floating-point divide by zero), the kernel hollers and issues a SIGFPE signal to the offending process. (By default, the program terminates with a message of the SIGFPE and a core dump is produced).
  • When you type ctrl-c, the kernel issues a SIGINT signal to the foreground process (and by default, the program is terminated).
  • When you type ctrl-z, the kernel issues a SIGTSTP signal to the foreground process (and by default, the process is suspended until a subsequent SIGCONT signal instructs it to resume).
  • Whenever a child process exits (either normally or abnormally), the kernel potentially delivers a SIGCHLD signal to the parent process.
    By default, the signal is ignored (and in fact, by default the kernel doesn't even deliver it unless the parent process registers an interest in receiving them). This particular signal type is instrumental to allowing forked child processes to run in the background while the parent process moves on to do its own work without blocking on a waitpid call. The parent process, however, is not relieved of its obligation to reap child process zombies, so the parent process will typically register code to be invoked whenever a child process terminates. Doing so prompts the kernel to begin issuing SIGCHLD signals so that the registered SIGCHLD handler can reap the zombies via waitpid.

• Here's a carefully coded example that illustrates how to implement and install a SIGCHLD handler (over two slides). The premise is that dad takes his five kids out to play. Each of the five children plays for a different length of time. When all five children are tired of playing, the six of them (five kids and their dad) all go home.
• Understand that the parent process is modeling dad, and that the child processes are modeling his children. (Code 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 spent doing other useful work
}

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 * kid); // sleep emulates "play" time
      printf("Child #%zu tired... returns to dad.\n", kid);
      return 0;
    }
  }

• Notice the use of the snooze function, which is my own implementation of an uninterruptable sleep:

  while (numChildrenDonePlaying < kNumChildren) {
    printf("At least one child still playing, so dad nods off.\n");
    snooze(5); // implementation in /usr/class/cs110/local/include/sleep-utils.h
    printf("Dad wakes up! ");
  }

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

• The above code is specifically crafted so each child process exits about 3 seconds apart. reapChild, of course, catches and handles each of the SIGCHLD signals delivered by the kernel as each forked child process exits. reapChild is contrived to take about a second to execute to completion, so each reapChild finishes about two seconds before the next child process exits.
• The signal function doesn't allow for state to be shared with the signal handler, so we have no choice but to use globals.
• Here's the fairly predictable output of the above program.

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

• 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;
    }
  }

• (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>

• 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.

• 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).

• 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>    

• All central themes of the course, and all very powerful features.
• Very difficult to understand and get right, and all kinds of concurrency issues and race conditions can appear unless you code very carefully.
• Consider the following program, which is a gesture to where your Assignment 4 shell will end up when it's all done (code for entire program can be found right here):

static void reapChild(int sig) {
  pid_t pid;
  while (true) {
    pid = waitpid(-1, NULL, WNOHANG);
    if (pid <= 0) break;
    printf("Job %d removed from job list.\n", pid);
  }
  exitUnless(pid == 0 || errno == ECHILD, kWaitFailed,
             stderr, "waitpid failed within reapChild sighandler.\n");
}

int main(int argc, char *argv[]) {
  exitIf(signal(SIGCHLD, reapChild) == SIG_ERR, kSignalFailed,
         stderr, "signal function failed.\n");
  for (size_t i = 0; i < 3; i++) {
    pid_t pid = fork();
    exitIf(pid == -1, kForkFailed,
           stderr, "fork function failed.\n");
    if (pid == 0) {
      char *listArguments[] = {"date", NULL};
      exitIf(execvp(listArguments[0], listArguments) == -1,
             kExecFailed, stderr, "execvp function failed.\n");
    }
    snooze(1); // represents meaningful time spent
    printf("Job %d added to job list.\n", pid);
  }

  return 0;
}

• How wrong is this?!!

myth22> ./job-list-synchronization
Wed Oct 11 9:45:41 PDT 2017
Job 26874 removed from job list.
Job 26874 added to job list.
Wed Oct 11 9:45:42 PDT 2017
Job 26875 removed from job list.
Job 26875 added to job list.
Wed Oct 11 9:45:43 PDT 2017
Job 26876 removed from job list.
Job 26876 added to job list.
myth22>

• The huge issue here is that each of the child processes (which quickly publish the date to the console via a fork/execvp pair) exits and prompts the kernel to fire a SIGCHLD signal at the parent before the parent makes it through its one second nap. The reapChild function executes in full (and "removes" the job from some job list) before the parent advances to the point where it "adds" the job to the same job list.
• That's messed up! Welcome to the land of concurrent contexts operating on shared data structures.
• The solution:
  • Informally, we need to programmatically block SIGCHLD signals from being handled until the parent manages to add the process to the job list.
  • Formally, we need to use sigset_t masks to temporarily block SIGCHLD signals from being handled until the parent has gotten through the code that adds the job to the job list.

• We must take steps to programmatically suspend the handling of SIGCHLD siganls until the parent is prepared to handle them.
• Enter the sigset_t type and the collection of functions that can be used to temporarily block the receipt of one or more signal types.
• Here's the working main function (code for entire program can be found right here):

int main(int argc, char *argv[]) {
  exitIf(signal(SIGCHLD, reapChild) == SIG_ERR, kSignalFailed,
         stderr, "signal function failed.\n");
  sigset_t mask;
  sigemptyset(&mask);
  sigaddset(&mask, SIGCHLD);
  for (size_t i = 0; i < 3; i++) {
    sigprocmask(SIG_BLOCK, &mask, NULL);
    pid_t pid = fork();
    exitIf(pid == -1, kForkFailed,
           stderr, "fork function failed.\n");
    if (pid == 0) {
      sigprocmask(SIG_UNBLOCK, &mask, NULL);
      char *listArguments[] = {"date", NULL};
      exitIf(execvp(listArguments[0], listArguments) == -1,
             kExecFailed, stderr, "execvp function failed.\n");
    }

    snooze(1);
    printf("Job %d added to job list.\n", pid);
    sigprocmask(SIG_UNBLOCK, &mask, NULL); // begin handling SIGCHLD signals again
  }    
  return 0;
}

• The sigset_t figure manages the set of signal types to be blocked and unblocked via calls to sigprocmask.
  • Note the call to sigprocmask(SIG_BLOCK, &mask, NULL);, which informs the kernel that the calling process isn't interested in handling any SIGCHLD events until after the spawned child process is added to the job list. Note, also, the call to sigprocmask(SIG_UNBLOCK, &mask, NULL); appears after the child process pid has been added to the job list (gestured via printf).
  • As it turns out, the forked process inherits the blocked signals vector, so it too needs to lift the block via its own call to sigprocmask(SIG_UNBLOCK, &mask, NULL);. In this example, it doesn't matter, but it would matter if the forked child process itself forked off child processes of its own.

myth22> ./job-list-synchronization
Wed Oct 11 9:49:23 PDT 2017
Job 29619 added to job list.
Job 29619 removed from job list.
Wed Oct 11 9:49:24 PDT 2017
Job 29620 added to job list.
Job 29620 removed from job list.
Wed Oct 11 9:49:25 PDT 2017
Job 29621 added to job list.
Job 29621 removed from job list.
myth22>

• Prototype:

int kill(pid_t pid, int signum);

• Analogous to the /bin/kill shell command.
  • Unfortunately named, since kill implies SIGKILL, which implies death.
  • So named because the default action of most signals in early UNIX implementations was to just terminate the target process (identified by pid).
• Returns -1 if the call fails (generally because the calling process doesn't have permission to fire signals at target process), 0 if all is swell.
• pid parameter is overloaded to provide many signalling strategies:
  • When pid is a positive number, the target is a process with that pid.
  • When pid is a negative number less than -1, the targets are all processes within the process group abs(pid).
  • pid can also be 0 or -1, but we don't need to worry about those (though it's documented in the B&O textbook if you're curious).

• We'll first work through a small puzzle to confirm you all understand the workflow of the processes and understand how kill triggers various signal handlers to be executed. (Error checking is omitted from this example, since it's so small, and we'll assume, for simplicity, that nothing ever fails).
• Putting it all together. What're the possible outputs (plural!) of the following program?

static pid_t pid;
static int counter = 0;

static void parentHandler(int unused) {       static void childHandler(int unused) {
  counter++;                                    counter += 3;
  printf("counter = %d\n", counter);            printf("counter = %d\n", counter);
  kill(pid, SIGUSR1);                         }
}



int main(int argc, char *argv[]) {
  signal(SIGUSR1, parentHandler);
  if ((pid = fork()) == 0) {
    signal(SIGUSR1, childHandler);
    kill(getppid(), SIGUSR1);
    return 0;
  }

  waitpid(pid, NULL, 0);
  counter += 7;
  printf("counter = %d\n", counter);
  return 0;
}

• Make sure you understand why the program on the previous slide is capable of producing two different outputs, depending on processor scheduling. (Hint: the child process may or may not exit before parentHandler has a chance to kill it!)

myth22> ./kill-puzzle
counter = 1
counter = 8
myth22> ./kill-puzzle
counter = 1
counter = 3
counter = 8
myth22>