• Program:
  • A file containing machine language instructions, the entry-point address, data, symbol and relocation tables, and other information
• Process:
  • An instance of a program execution

• Purpose of Signals:
  • Interrupt the normal flow of execution
• Use:
  • Notify a process that an event has occurred
• A Hardware Analogy:
  • Exceptions/Interrupts

• Parties:
  • Kernel and and process
  • Two processes
  • One process (i.e., sending a signal to itself)
• Identification:
  • Each signal is a unique small integer (defined in <signal.h> )
• Categories:
  • Standard - numbered from 1 to 31
  • Realtime - all others

• Resulting from Hardware Exceptions:
  • Divide by zero
  • Referencing inaccessible memory
• Special User Input:
  • Interrupt (usually Ctrl+C)
  • Suspend (usually Ctrl+Z)
• Software Events:
  • Input became available on a file descriptor
  • A child terminated
  • A terminal window was resized

• Generation:
  • Signals are said to be generated by an event
• Delivery:
  • Signals are said to be delivered to a process
• Pending:
  • Signals are said to be pending between the time they are generated and the time they are delivered

• Normally:
  • A pending signal is delivered as soon as the receiving process is next scheduled to run
• Blocking Delivery:
  • To ensure that a block of code is not interrupted by the delivery of a particular signal we can add that signal to the process's signal mask (in which case it will remain pending until it is later removed from the mask)

• Signals Are Not Queued:
  • The set of pending signals is represented by a bit vector (where the bits correspond to the signal numbers) which means there can be only one pending signal with a particualr number at a time
• Interrupting Handlers:
  • Handlers can, themselves, be interrupted by signals
• Implicit Blocking:
  • By default, the kernel blocks pending signals of the type currently being processed

• Ignored:
  • The process never knows the signal was generated
• Terminated:
  • The process is killed (called abnormal termination) with or without a core dump
• Stopped:
  • Execution of the process is suspended
• Resumed:
  • Execution of the process is resumed (after having been stopped previously)

• An Observation:
  • The default effect is not always what is desired
• Possible Dispositions:
  • The default
  • The signal is ignored
  • A signal handler (i.e., a function written for the purpose of handling the signal) is executed

• Installing/Establishing:
  • Notifying the kernel that a signal handler should be invoked
• Handling/Catching:
  • Invoking a signal handler

#include <signal.h>

Understanding the Signature:

handler is a pointer to a function that returns nothing and is passed an int.

signal() itself returns a pointer to a function that returns nothing and is passed an int.

• Add a Type Definition:
  • typedef void (*signalhandler_t)(int);
• The "New" Prototype for signal():
  • sighandler_t signal(int num, sighandler_t handler);

• SIG_DFL:
  • Reset the disposition of the signal to its default
• SIG_IGN:
  • Ignore the signal

• Non-Portability of signal():
  • Some systems restore the action for a signal to its default after it has been caught by a handler
  • On some systems, slow system calls (e.g., read(), wait()) that are interrupted by a signal do not resume when the handler returns (instead they return immediately and set errno to EINTR)
• The Posix Standard:
  • sigaction() allows the caller to specify all behaviors in a standard way (but it is complicated to use)

#include <signal.h>

Note: struct sigaction contains a pointer to the signal handler, the additional signals to be blocked, flags, etc...

• What it Does:
  • Sends a signal to a process (if the ID is positive) or process group (if the ID is negative)
• Examples:
  • kill -9 22807 sends signal 9 (i.e., SIGKILL) to process 22807
  • kill -19 -11975 sends signal 19 (i.e., SIGSTOP) to process group 11975

• Recall:
  • Terminals are responsible for the handling of some special characters
• Some Important Examples:
  • Ctrl+C sends a SIGINT to every process in the foreground process group (which, unless the default action has been modified, terminates the process)
  • Ctrl+Z sends a SIGTSTP to every process in the foreground process group (which, unless the default action has been modified, suspends the process)

#define _POSIX_SOURCE
#include <sys/types.h>
#include <signal.h>

Note: A signal will only be sent to processes for which the calling process has the appropriate permission

• In the Abstract:
  • When one process needs to notify another process of an event and coordination is unimportant
• Examples:
  • Changing the volume of a media player
  • Stopping an iterative calculation
  • Informing a process of a state change

• In the Abstract:
  • When one process needs to send a single bit of information to another process (i.e., an "alert")
• Examples:
  • Do/Don't calculate some value
  • Something does/doesn't exist

• The Setting:
  • A point of sales system that needs to calculate the total sales and the sales tax
  • Some customers are "tax exempt"
• A Conventional System:
  • Calculate the tax status first (which takes time), then calculate the total sales (which takes time), then calculate the sales tax (which is essentially instantaneous)

unixexamples/signals/tax0.c

        #include <stdio.h>
#include "tax_lib.h"

int
main(void)
{
  float rate, sales, tax;
  int   should;

  setup();
  rate = 0.05;

  should = should_tax();
  sales = total_sales();
  if (should) tax = sales * rate;
  else        tax = 0.0;

  printf("Tax: %5.2f\n", tax);
}
        

• An Observation:
  • The conventional system always requires additive time
• Using Concurrency:
  • Calculate the tax status using a child process
  • Calculate the total sales in the parent process
  • After both of the above are done, calculate the tax in the parent process
• Possible Advantage:
  • If the parent doesn't have to wait for the child then the system only requires as much time as the parent
  • If the parent has to wait for the child then the system only requires as much time as the child

unixexamples/signals/tax1.c

        #include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <unistd.h>
#include "tax_lib.h"

int
main(void)
{
  float rate, sales, tax;
  int   should, status;
  pid_t pid;

  should = 0;
  rate   = 0.05;
  pid    = fork();
  switch(pid)
    {
    case -1:
      exit(1);

    case 0:
      should = should_tax();
      break;

    default:
      sales = total_sales();
      wait(&status); // Note: There is only one child
      if (should) tax = sales * rate;
      else        tax = 0.0;
      printf("Tax: %5.2f\n", tax);
      break;
    }
}
        

• Understanding the Defect:
  • What value will should have in the two processes? Why won't giving should file scope fix it?

• An Observation:
  • The child process needs to communicate information to the parent
• Why a Signal Can Work:
  • Since the information to be communicated is binary (i.e., tax exempt or not), a (single) signal can be used

unixexamples/signals/tax2.c

        #define _POSIX_SOURCE
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <sys/types.h>
#include <unistd.h>
#include "tax_lib.h"

volatile int should = 0;

static void
sighandler(int sig)
{
  should = 1;
}

int
main(void)
{
  float rate, sales, tax;
  int   status;
  pid_t pid;

  rate   = 0.05;
  pid    = fork();

  signal(SIGUSR1, sighandler);

  switch(pid)
    {
    case -1:
      exit(1);

    case 0:
      if (should_tax()) kill(getppid(), SIGUSR1);
      break;

    default:
      sales = total_sales();
      wait(&status); // Note: There is only one child
      if (should) tax = sales * rate;
      else        tax = 0.0;
      printf("Tax: %5.2f\n", tax);
      break;
    }
}
        

• An Observation:
  • We could use a simple coordination protocol in the previous example because the parent could wait until the process terminated
• Other Situations:
  • This isn't the case either for efficiency reasons or for other reasons
• The Implication:
  • In general, because they are transient, signals are not a good tool for coordination

• A Small Change to the Earlier Example:
  • After the child process calculates the status it must perform another task
  • This other task takes a long time and the parent doesn't need the result
• The Implication:
  • There is no reason for the parent to wait() for the child to terminate

• Ten Thousand Monkeys at Ten Thousand Keyboards:
  • Remove the call to wait()
• The Defect:
  • The parent may finish calculating the total sales before the signal has been sent
• What's Needed:
  • Put the parent in the stopped state until it receives the signal (rather than until the child terminates)

#include <unistd.h>

Note: The sleep() function puts the calling process in the stopped state until a given amount of time passes or it is interrupted by a signal.

The Goal: Sequence Task 1 Before Task 2

unixexamples/signals/sequence.c

        #define _POSIX_SOURCE
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

static void
handle_continue(int sig)
{
  // Nothing to do but interrupt the call to pause()
}

/*
 * The Goal:           Sequence Task 1 before Task 2
 * The Race Condition: kill() in child may be called before pause() in parent
 */
int
main(void)
{
  // Setup the signal handler
  signal(SIGCONT, handle_continue);

  pid_t  pid = fork();
  switch(pid)
    {
    case -1:
      exit(1);

    case 0:  // Child
      printf("Task 1\n");
      kill(getppid(), SIGCONT);
      exit(0);

    default: // Parent
      pause();
      printf("Task 2\n");
      exit(0);
    }
}
        

The Race Condition: The child process might call kill() before the parent process calls pause().

• What We Have:
  • A mechanism for "pausing" the parent
• What We Don't Have:
  • A correct coordination protocol

unixexamples/signals/tax3.c

        #define _POSIX_SOURCE
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include "tax_lib.h"

// An example with a fairly obvious race condition

volatile int should = 0;

static void
sighandler(int sig)
{
  should = 1;
}

int
main(void)
{
  float rate, sales, tax;
  pid_t pid;

  rate   = 0.05;
  pid    = fork();

  signal(SIGUSR1, sighandler);

  switch(pid)
    {
    case -1:
      exit(1);

    case 0:
      if (should_tax()) kill(getppid(), SIGUSR1);
      record_status(); // This takes a long time
      break;

    default:
      sales = total_sales();
      pause();
      if (should) tax = sales * rate;
      else        tax = 0.0;
      printf("Tax: %5.2f\n", tax);
      break;
    }
}
        

• The Race Condition:
  • If it takes the parent longer to calculate the total sales than it takes the child to calculate the status then the signal will be generated and delivered before the call to pause() and pause() will never return.

• The Situation:
  • A signal interrupts a block of code that shouldn't be interrupted (i.e., a critical section)
• What We Can't Do:
  • Prevent the signal from being generated
• What We Can Do:
  • Prevent the signal from being delivered

#include <signal.h>

how can be SIG_BLOCK to make blocked = blocked | set, SIG_UNBLOCK to make blocked = blocked & ~set, or SIG_SETMASK to make blocked = set.

• Initializing Signal Sets:
  • sigemptyset() initializes the given set to the empty set
  • sigfillset() adds every signal to the given set
• Manipulating Signal Sets:
  • sigaddset() adds a given signal number to the given set
  • sigdelset() removes a given signal number to the given set

unixexamples/signals/tax4.c

        #define _POSIX_SOURCE
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include "tax_lib.h"

// An example with a more subtle race condition

volatile int should = 0;


static void
sighandler(int sig)
{
  should = 1;
}

int
main(void)
{
  float    rate, sales, tax;
  pid_t    pid;
  sigset_t set, oldset;
  
  rate   = 0.05;
  pid    = fork();

  signal(SIGUSR1, sighandler);

  sigemptyset(&set);
  sigaddset(&set, SIGUSR1);
  sigprocmask(SIG_BLOCK, &set, &oldset);

  switch(pid)
    {
    case -1:
      exit(1);

    case 0:
      if (should_tax()) kill(getppid(), SIGUSR1);
      record_status(); // This takes a long time
      break;

    default:
      sales = total_sales();
      sigprocmask(SIG_SETMASK, &oldset, NULL);
      pause();
      if (should) tax = sales * rate;
      else        tax = 0.0;
      printf("Tax: %5.2f\n", tax);
      break;
    }
  return 0;
}
        

• The Race Condition:
  • The signal could be delivered to the parent process before pause() is invoked, in which case pause() will never return.

• A Common Mistake:
  • Using the following three statements

            sigprocmask(SIG_BLOCK, &set, &oldset);
            pause();
            sigprocmask(SIG_BLOCK, &oldset, NULL);
            

• The Race Condition:
  • A signal might be received after the first call to sigprocmask() but before the call to pause()

#include <signal.h>

sigsuspend() is essentially the same as the three calls above, but the first two calls are atomic.

• Keep Handlers Simple:
  • Often this means that the handler only sets a flag and returns (in a sense, providing a persistence mechanism)
• Only Call "Signal Safe" Functions:
  • See signal for a list (which, notably, does not include printf() or exit())
• Protect Access to Shared Global Data:
  • Temporarily block all signals while using such data

• Declare Global Variables with volatile:
  • Forces the compiler to read the value from memory (not a cache) each time the variable is referenced
• Declare Flags with sig_atomic_t:
  • Guarantees reads and writes are atomic

• Not Interruptible:
  • For obvious reasons, it can't calls functions that can be interrupted by a signal
• Reentrancy:
  • One Definition - A function is reentrant if its execution can be interrupted and it can be called again (before the previous invocation is completed)
  • Another Definition - A function is reentrant if its instructions are invariant and, hence, can be shared across instances