March 22, 2006

---

Basic Signal Review

---

• blocking != ignoring
• ignoring is a special case of catching and handling
• so really, we should say, blocking != catching
• process signal mask gives currently blocked signals
• sigset_t, a signal set, how, set, oset
• to block signals, use sigprocmask
  • SIG_BLOCK, SIG_UNBLOCK, and SIG_SETMASK
  • sigaddset, sigdelset, sigemptyset, sigfillset, and sigismember
  • SIGSTOP and SIGKILL (9) cannot be blocked
• to catch and handle signals, use sigaction (and not signal, which is unreliable)
  • sig, act, and oact
  • SIG_DFL and SIG_IGN
  • a user-defined handler is a void function which takes one integer argument

---

Examples of Blocking Signals

---

• blocktest.c: a program which blocks and unblocks SIGINT
• makepair.c: a function which blocks all signals while creating two named pipes
  • intent is to ensure the deallocation of both pipes should an error occur
• blockchild.c: a program which blocks signals before calling fork and execl
  • child cannot restore original mask after exec, why?
• password.c: a function which blocks some signals which, if delivered, might put the terminal in unusable state, during password entry

---

More Examples of Handling Signals

---

• handlectrlc.c: a program which sets up a signal handler for <ctrl-c>
  • notice that execution resumes at the statement immediately following a sleep interrupted by the signal
    • add another sleep to verify that the <ctrl-c> is actually being handled
  • order in which blocked signals are delivered is arbitrary and only one of a kind is delivered
• signalterminate.c: a program which which terminates gracefully when it receives a <ctrl-c>
  • accesses to doneflag is a critical section
    • handler should not modify it while main is examining it
    • sig_atomic_t: an integral type that ensures atomic access
    • use of volatile qualifier suppresses compiler optimization, such as only evaluating the loop condition before the first iteration, that might otherwise occur
    • in this case, the use of volatile informs the compiler that doneflag may be changed asynchronously to the program's execution
• averagesin.c: a program to estimate the average values of sin(x) over the interval from 0 to 1
  • access to the results string is the critical section of this program
    • we do not want main modifying the string while the handler is writing it to standard output
      • thus, main blocks SIGUSR1 while modifying the results string
  • example of case where we might want to send a signal to ourself

---

Introduction to Waiting for Signals Efficiently

---

• we want to avoid busy waiting (e.g., while ( ... );) when waiting on a particular signal
• signals provide a mechanisms to avoid busy waiting
• pause: suspends calling thread until the delivery of a signal
• first example:

  static volatile sig_atomic_t sigreceived = 0;
  
  while (sigreceived == 0)
     pause();
  

  • here embedding pause inside a while loop simulates a wait for a particular signal
    • because the signal handler for that particular signal will set sigreceived
  • what happens if the desired signal is received between the test and call to pause?
    • the handler sets sigreceived, but pause still causes the thread to wait until that signal or another is received
• second example:

  static volatile sig_atomic_t sigreceived = 0;
  
  int signum;
  sigset_t sigset;
  
  sigemptyset (&sigset);
  sigaddset (&sigset, signum);
  sigprocmask (SIGBLOCK, &sigset, NULL);
  
  while (sigreceived == 0)
     pause();
  

  • here, we are trying to prevent the delivery of a signal between the test and call to pause by blocking
  • problem: the desired signal is blocked; pause will never return
  • so why not unblock it immediately before the call to pause?
    • catch-22; see example 1
  • we really want to perform two operations (unblocking and the call to pause) in one stroke
  • there must be a solution? what to do? use sigsuspend; to be continued ....

---

References

[USP] K. A. Robbins and S. Robbins. UNIX Systems Programming: Concurrency, Communication, and Threads. Prentice Hall, 2003