CS110 Lecture 07: Signals

PDF of this presentation

Principles of Computer Systems

Winter 2020

Stanford University

Computer Science Department

Instructors: Chris Gregg and

Nick Troccoli

CS110 Topic 2: How can our programs create and interact with other programs?

Learning About Processes

Creating processes and running other programs

Inter-process communication

Signals

Race Conditions

1/15

1/22

Today

1/29

Today's Learning Goals

Introduce signals as another way for processes to communicate
Learn how to execute code in our program when we receive a signal
Learn how to block and resume signals

Plan For Today

Introducing Signals
Demo: Disneyland
Signals Aren't Queued
Demo: Return Trip To Disneyland
Concurrency
Blocking Signals
Demo: Revisiting Our Shell
Waiting For Signals

Plan For Today

Introducing Signals
Demo: Disneyland
Signals Aren't Queued
Demo: Return Trip To Disneyland
Concurrency
Blocking Signals
Demo: Revisiting Our Shell
Waiting For Signals

Interprocess Communication

It's useful for a parent process to be able to communicate with its child (and vice versa)
There are two key ways we will learn to do this: pipes and signals
- Pipes let two processes send and receive arbitrary data
- Signals let two processes send and receive certain "signals" that indicate something special has happened.

Signals

A signal is a way to notify a process that an event has occurred

There is a list of defined signals that can be sent (or you can define your own): SIGINT, SIGSTOP, SIGKILL, SIGCONT, etc.
A signal is really a number (e.g. SIGSEGV is 11)
A program can have a function executed when a type of signal is received
Signals are sent either by the operating system, or by another process
You can send a signal to yourself or to another process you own

Signals

Here are some examples of signals:

SIGINT - when you type Ctl-c in the terminal, the kernel sends a SIGINT to the foreground process group. The default behavior is to terminate.
SIGTSTP - when you type Ctl-z in the terminal, the kernel sends a SIGTSTP to the foreground process group. The default behavior is to halt it until it is told to continue.
SIGSEGV - when your program attempts to access an invalid memory address, the kernel sends a SIGSEGV ("seg fault"). The default behavior is to terminate.

Process Lifecycle

Running - a process is either executing or waiting to execute

Stopped - a process is suspended due to receiving a SIGSTOP or similar signal. A process will resume if it receives a SIGCONT signal.

Terminated - a process is permanently stopped, either due to finishing, or receiving a signal such as SIGSEGV or SIGKILL whose default behavior is to terminate the process.

When a child changes state, the kernel sends a SIGCHLD signal to its parent.

Sending Signals

The operating system sends many signals, but we can also send signals manually.

kill sends the specified signal to the specified process (poorly-named; previously, default was to just terminate target process)
pid parameter can be > 0 (specify single pid), < -1 (specify process group abs(pid)), or 0/-1 (we ignore these).
raise sends the specified signal to yourself

int kill(pid_t pid, int signum);

// same as kill(getpid(), signum)
int raise(int signum);

waitpid()

Waitpid can be used to wait on children to terminate or change state:

pid_t waitpid(pid_t pid, int *status, int options);

pid: the PID of the child to wait on, or -1 to wait on any of our children
status: where to put info about the child's status (or NULL)
the return value is the PID of the child that was waited on, -1 on error, or 0 if there are other children to wait for, but we are not blocking.

The default behavior is to wait for the specified child process to exit. options lets us customize this further (can combine these flags using | ):

WUNTRACED - also wait on a child to be stopped
WCONTINUED - also wait on a child to be continued
WNOHANG - don't block

Signal Handlers

We can have a function of our choice execute when a certain signal is received.

We must register this "signal handler" with the operating system, and then it will be called for us.

signum is the signal (e.g. SIGCHLD) we are interested in.
handler is a function pointer for the function to call when this signal is received.
(Note: no handlers allowed for SIGSTOP or SIGKILL)

typedef void (*sighandler_t)(int);
...
sighandler_t signal(int signum, sighandler_t handler);

Plan For Today

Introducing Signals
Demo: Disneyland
Signals Aren't Queued
Demo: Return Trip To Disneyland
Concurrency
Blocking Signals
Demo: Revisiting Our Shell
Waiting For Signals

Signal Handlers (five-children.c)

// five-children.c
static const size_t kNumChildren = 5;
static size_t numChildrenDonePlaying = 0;

static void reapChild(int sig) {
  waitpid(-1, NULL, 0);
  numChildrenDonePlaying++;
}

int main(int argc, char *argv[]) {
  printf("Let my five children play while I take a nap.\n");
  signal(SIGCHLD, reapChild);
  for (size_t kid = 1; kid <= kNumChildren; kid++) {
    if (fork() == 0) {
      sleep(3 * kid); // sleep emulates "play" time
      printf("Child #%zu tired... returns to parent.\n", kid);
      return 0;
    }
  }

  while (numChildrenDonePlaying < kNumChildren) {
    printf("At least one child still playing, so parent nods off.\n");
    snooze(5); // custom fn to sleep uninterrupted
    printf("Parent wakes up! ");
  }  
  printf("All children accounted for.  Good job, parent!\n");
  return 0;
}

In this program, a parent takes their five children out to play. Each of the five children plays for a different length of time. When all five kids are done playing, the six of them all go home.
Similar to many parallel data processing applications where parent does other work while children are busy
(Full program is right here.)

Signal Handlers

A signal can be received at any time, and a signal handler can execute at any time.

Signals aren't handled immediately (there can be delays)
Signal handlers can execute at any point during the program execution (eg. pause main() execution, execute handler, resume main() execution)
- Goal: keep signal handlers simple!
Similar to hardware interrupts -- POSIX brings that model to software

Signal Handlers (five-children.c)

// five-children.c
static const size_t kNumChildren = 5;
static size_t numChildrenDonePlaying = 0;

static void reapChild(int sig) {
  waitpid(-1, NULL, 0);
  numChildrenDonePlaying++;
}

int main(int argc, char *argv[]) {
  printf("Let my five children play while I take a nap.\n");
  signal(SIGCHLD, reapChild);
  for (size_t kid = 1; kid <= kNumChildren; kid++) {
    if (fork() == 0) {
      sleep(3); // sleep emulates "play" time
      printf("Child #%zu tired... returns to parent.\n", kid);
      return 0;
    }
  }

  while (numChildrenDonePlaying < kNumChildren) {
    printf("At least one child still playing, so parent nods off.\n");
    snooze(5); // custom fn to sleep uninterrupted
    printf("Parent wakes up! ");
  }  
  printf("All children accounted for.  Good job, parent!\n");
  return 0;
}

What happens if all children sleep for the same amount of time? (E.g. change line 15 from sleep(3 * kid) to sleep(3)).

Plan For Today

Introducing Signals
Demo: Disneyland
Signals Aren't Queued
Demo: Return Trip To Disneyland
Concurrency
Blocking Signals
Demo: Revisiting Our Shell
Waiting For Signals

Signal Handlers

Problem: a signal handler is called if one or more signals are sent.

Like a notification that "one or more signals are waiting for you!"
The kernel tracks only what signals should be sent to you, not how many
When we are sleeping, multiple children could terminate, but result in 1 SIGCHLD!

Solution: signal handler should clean up as many children as possible.

Signal Handlers

static void reapChild(int sig) {
  waitpid(-1, NULL, 0);
  numChildrenDonePlaying++;
}