Applying Design Patterns to Simplify Signal Handling

It's remarkable how many seemingly vexing programming problems can be resolved by knowledge of basic design patterns. The purpose of this article is to demonstrate how patterns like Singleton [GOF], Adapter [GOF], and Hook Method [Pree] can simplify the development of components that avoid common traps and pitfalls associated with signals and signal handling.

1. Technical Background on Signals

There are a wide variety of signals, including:

• SIGSEGV -- which is trapped by the hardware, e.g., when a NULL pointer is dereferenced;

• SIGALRM -- which indicates the the expiration of a software timer;

• SIGINT -- which occurs when a user types a break character, such as control-C.

When the OS raises a signal that an application has registered to handle, the currently executing function is ``pinned'' by the signal handler function. To accomplish this, the OS first pushes a new activation record on top of the process' run-time stack. Next, it automatically invokes the application's pre-registered signal handler function. When this function completes, the OS pops off the signal handler context and returns control back to the point where the program was executing before the signal occurred.

2. Signal Handler Example

/* Global variables that control 
   process shutdown. */
sig_atomic_t graceful_quit = 0;
sig_atomic_t abortive_quit = 0;

/* Signal handler for SIGINT. */
void SIGINT_handler (int signum)
{
  assert (signum == SIGINT);
  graceful_quit = 1;
}

/* Signal handler for SIGQUIT. */
void SIGQUIT_handler (int signum)
{
  assert (signum == SIGQUIT);
  abortive_quit = 1;
}

/* ... */

int main (void)
{
  struct sigaction sa;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = 0;

  /* Register the handler for SIGINT. */
  sa.sa_handler = SIGINT_handler;
  sigaction (SIGINT, &sa, 0);

  /* Register the handler for SIGQUIT. */
  sa.sa_handler =  SIGQUIT_handler;
  sigaction (SIGQUIT, &sa, 0);

  /* Run the main event loop. */
  while (graceful_quit == 0 
         && abortive_quit == 0) 
    do_work ();

  if (abortive_quit == 1) {
    _exit (1);
  }
  else if graceful_quit {
    clean_up ();
    exit (0);
  }

  /* NOTREACHED */
}

In this particular example, the delivery of the SIGINT signal triggers a graceful shut down of the application's event loop. Likewise, the delivery of the SIGQUIT signal triggers an abortive shut down by calling _exit. Unlike exit, _exit doesn't cleanup global resources, such as C standard I/O buffers, etc.

2.1. Common Traps and Pitfalls

In general, the use of global variables in signal handler functions in C++ programs causes an ``impedance mismatch.'' In particular, it presents a conflict between (1) the global-variables required to interact with signal handlers and (2) the well-structured OO design used for other application processing.

2.2. Solution

A. Define a Hook Method Interface

class Event_Handler
{
public:
  // Hook method for the signal hook method.
  virtual int handle_signal (int signum) = 0;

  // ... other hook methods for other types of
  // events such as timers, I/O, and 
  // synchronization objects.
};

B. Define a Signal Handler Component as a Singleton

The Adapter pattern transforms one interface into another interface that is more appropriate for clients. This pattern is used in the Signal_Handler component to adapt the C-style signal handling functions required by sigaction into the C++ methods defined by concrete event handlers.

The Hook Method pattern enables general-purpose algorithm code to perform some steps supplied by an application-specific callback method. This pattern decouples the generic signal registration and dispatching logic in the Signal_Handler component from the application-specific behavior performed when the handle_signal hook method is invoked on a concrete event handler.

The following C++ code illustrates the application of these patterns to develop the Signal_Handler singleton component.

class Signal_Handler
{
public:
 // Entry point.
 static Signal_Handler *instance (void);

 // Register an event handler <eh> for <signum>
 // and return a pointer to any existing <Event_Handler>
 // that was previously registered to handle <signum>.
 Event_Handler *register_handler (int signum,
		                  Event_Handler *eh);

 // Remove the <Event_Handler> for <signum>
 // by setting the slot in the <signal_handlers_>
 // table to NULL.
 int remove_handler (int signum);

private:
 // Ensure we're a Singleton.
 Signal_Handler (void); 

 // Singleton pointer.
 static Signal_Handler *instance_;

 // Entry point adapter installed into <sigaction> 
 // (must be a static method or a stand-alone 
 // extern "C" function).
 static void dispatcher (int signum);

 // Table of pointers to concrete <Event_Handler>s
 // registered by applications.  NSIG is the number of 
 // signals defined in </usr/include/sys/signal.h>.
 static Event_Handler *signal_handlers_[NSIG];
};

The following example illustrates the use of signal chaining to ensure that the EPIPE is handled appropriately during a write system call to a network socket connection:

class EPIPE_Handler : public Event_Handler
{
public:
  virtual int handle_signal (int signum);
  // Handle the SIGPIPE signal appropriately.

  // ...
};

EPIPE_Handler epipe_handler;

ssize_t
sigsafe_write (int socket, 
               const char *buf,
               size_t len)
{
  Event_Handler *oeh;

  // Temporarily replace any existing 
  // signal handler with a special handler
  // for the EPIPE signal for the duration 
  // of this function.
  oeh = Signal_Handler::instance ()->
          register_handler (SIGPIPE, 
                            &epipe_handler);

  ssize_t n = write (socket, buf, len);

  // Restore the original signal handler.
  Signal_Handler::instance ()->
    register_handler (SIGPIPE, oeh);

  return n;
}

Event_Handler *
Signal_Handler::register_handler (int signum,
				  Event_Handler *eh)
{
  // Copy the <old_eh> from the <signum> slot in 
  // the <signal_handlers_> table.
  Event_Handler *old_eh =
    Signal_Handler::signal_handlers_[signum];

  // Store <eh> into the <signum> slot in the
  // <signal_handlers_> table.
  Signal_Handler::signal_handlers_[signum] = eh;
 
  // Register the <dispatcher> to handle this
  // <signum>.
  struct sigaction sa;
  sa.sa_handler = Signal_Handler::dispatcher;
  sigemptyset (&sa.sa_mask);
  sa.sa_flags = 0;
  sigaction (signum, &sa, 0);

  return old_eh;
}

   
void Signal_Handler::dispatcher (int signum)
{
  // Perform a sanity check...
  if (Signal_handler::signal_handlers_[signum] != 0)
    // Dispatch the handler's hook method.
    Signal_handler::signal_handlers_
      [signum]->handle_signal (signum);
}

Note how the signum received by the dispatcher is passed through to the handle_signal hook method. This enables handle_signal to determine which signal it is handling. Therefore, the same concrete event handler can be programmed to handle different signals in different ways.

C. Define the Concrete Event Handlers

class SIGINT_Handler : public Event_Handler
{
public:
  SIGINT_Handler (void)
    : graceful_quit_ (0) {}

  // Hook method.
  virtual int handle_signal (int signum)
  {
    assert (signum == SIGINT);
    this->graceful_quit_ = 1;
  }

  // Accessor.
  sig_atomic_t graceful_quit (void)
  { return this->graceful_quit_; }

private:
  sig_atomic_t graceful_quit_;
};

The following is a concrete event handler that handles SIGQUIT.

class SIGQUIT_Handler : public Event_Handler
{
public:
  SIGQUIT_Handler (void)
    : abortive_quit_ (0) {}

  // Hook method.
  virtual int handle_signal (int signum)
  {
    assert (signum == SIGQUIT);
    this->abortive_quit_ = 1;
  }

  // Accessor.
  sig_atomic_t abortive_quit (void)
  { return this->abortive_quit_; }

private:
  sig_atomic_t abortive_quit_;
};

D. Register Event Handler Subclasses with Signal Handler Singleton

int main (void)
{
  SIGINT_Handler sigint_handler;
  SIGQUIT_Handler sigquit_handler;

  // Register the handler for SIGINT.  
  Signal_Handler::instance ()->register_handler 
    (SIGINT, &sigint_handler);

  // Register the handler for SIGQUIT.
  Signal_Handler::instance ()->register_handler 
    (SIGQUIT, &sigquit_handler);

  // Run the main event loop. 
  while (sigint_handler.graceful_quit () == 0
         && sigquit_handler.abortive_quit () == 0) 
    do_work ();

  if (sigquit_handler.abortive_quit () == 1) 
    _exit (1);
  else /* if sigint_handler.graceful_quit () */ {
    clean_up ();
    return 1;
  }
}

There are many variations on this basic design. For instance, we could support other sigaction semantics using various flags and sigmasks. Likewise, we could allowing multple Event_Handlers to be registered per-signal. In addition, we could support the POSIX extended signal API. However, the fundamental essence of all these solution involves recognizing the power of several basic patterns: Singleton, Adapter, and Hook Method.

3. Caveats

Programming with signals also can be overly complex due to timing problems and race conditions when the current thread of control is preempted by a signal handler. Likewise, debugging programs that use asynchronous signals is hard since events occur at different points of time during program execution.

However, if you decide that your applications require signals and signal handling, knowledge of the patterns and OO design components described in this article can be invaluable to simplify your programming tasks.

4. Concluding Remarks

The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, interprocess communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchronization. ACE is freely available via the WWW at URL www.dre.vanderbilt.edu/~schmidt/ACE.html.

Thanks to Achint Sandhu <sandhu@nortel.ca> for comments on this paper.

References

[GoF] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Reading, MA: Addison-Wesley, 1995.

[Pree] Wolfgang Pree, Design Patterns for Object-Oriented Software Development, Addison-Wesley, Reading, MA, 1994.

[Schmidt] Douglas C. Schmidt, ACE: an Object-Oriented Framework for Developing Distributed Applications, Proceedings of the 6th USENIX C++ Technical Conference, Cambridge, Massachusetts, April, 1994.

[Stevens] W. Richard Stevens, ``UNIX Network Programming,'' Second Edition, Prentice Hall, Englewood Cliffs, NJ, 1997.

Back to C++ Report Editorials home page.

Last modified 11:34:51 CDT 28 September 2006