Preventing Glitches in Signal Processing

Submit New Article

Last Modified On :   October 3, 2008 5:46 PM PDT
Rate
 


by Danny Kalev, C++ Pro

Introduction

Signals are similar to hardware interrupts. They cause a process to branch from the current execution flow, perform a specific action, and resume execution from the point of interruption. In the following sections, I will dissect the ANSI <signal.h> library and demonstrate how to use its interfaces. We will then proceed to the POSIX signal API @ http://www.burningvoid.com/iaq/posix-signals.html*.

By default, certain signals cause a process to terminate. For example, an attempt to access memory that the process doesn't own fires a SIGSEGV ("segmentation fault") signal, which in turn aborts the process. Yet for many applications, this is undesirable. Debuggers, emulators, and transaction processing systems must handle such signals and continue to run.

The Problem

By default, certain signals cause a process to terminate, no questions asked. How can this be prevented?

The Solution

Install handlers for incoming signals and catch them when they occur.

Step-by-Step

Step 1: Setting a Handler

A signal is an integer value that the kernel delivers to a process. When a process receives a signal, it can react in one of the following manners:

  • Ignore the signal;
  • Let the kernel perform the default operation* associated with that signal;
  • Catch the signal, i.e., have the kernel transfer control to a signal handler and resume the program from the place of interruption once the handler returns. A signal handler is a function that the kernel automatically invokes when a signal occurs. The signal() function registers a handler for a given signal:

 

typedef void (*handler)(void);

void * signal(int signum, handler);

 

The first argument is the signal's code. The second argument is an address of a user-defined function to be called when the signal signum occurs.

Instead of a function's address, the second argument may take two special values: SIG_IGN and SIG_DFL. SIG_IGN indicates that the signal should be ignored (note however that the SIGKILL and SIGSTOP signals cannot be blocked, caught, or ignored); SIG_DFL instructs the kernel to perform the default action when the signal is raised.

Step 2: Signaling

There are three ways to signal a process:

  • A process explicitly sends a signal to itself by calling raise();
  • A signal is sent from another process, say by using t he kill() system call or a Perl script*;
  • A signal is sent from the kernel. For instance, when the process has attempted to access memory it doesn't own or during system shutdown.


Step 3: Raising and Handling a Signal

The following program registers a SIGTERM handler. It then raises a SIGTERM signal thereby causing the handler to run:

#include <csignal>

#include <iostream>

using namespace std;

void term(int sig)

{

//..necessary cleanup operations before
terminating

cout << "handling signal no." <<sig<<endl;

}

int main()

{

signal(SIGTERM, term); // register a SIGTERM handler

raise(SIGTERM); // will cause term() to run

}

 

ANSI <signal.h> Limitations

What happens when a process that is already running a handler for a SIGx signal receives another SIGx signal? One solution is to let the kernel interrupt the process and run the handler once more. To allow this, the handler must be re-entrant*. However, designing re-entrant handlers is too complicated. The ANSI C solution to the recurring signal* problem is to reset the handler to SIG_DFL before executing the user-defined handler. This is problematic, though.

When two signals occur quickly, the kernel runs the handler for the first signal and performs the default action for the second one, which might terminate the process.

Several alternative signal frameworks have evolved in the past three decades, each of which offers a different solution to the recurring signal problem. The POSIX signal API* is the most mature and portable among them.

POSIX Signals

The POSIX signal functions operate on sets of signals packed in a sigset_t datatype:

  • int sigemptyset(sigset_t * pset); Clears all the signals in pset.
  • int sigfillset(sigset_t * pset); Fills pset with all available signals.
  • int sigaddset( sigset_t * pset, int signum); Adds signum to pset.
  • int sigdelset(sigset_t * pset, int signum); Removes signum from pset.
  • int sigismember(const sigset_t * pset, int signum); Returns a nonzero value if signum is included in pset, 0 otherwise.


Sigaction() registers a handler for a specific signal:

int sigaction

(int signum, struct sigaction * act, struct sigaction
*prev);

 

The sigaction struct describes the kernel's handling of signum:

struct sigaction

{

sighanlder_t sa_hanlder;

sigset_t sa_mask; // list of signals to block

unsigned long sa_flags; // blocking mode

void (*sa_restorer)(void); // never used

};

 

sa_hanlder holds an address of a function that takes int and returns no value. It can also take one of two special values: SIG_DFL and SIG_IGN.

Additional Features

The POSIX API offers various services not present in the ANSI library. These include the ability to block incoming signals and retrieve currently pending signals.

Blocking Signals

The sigprocmask() blocks and unblocks signals:

int sigprocmask(int mode, const sigset_t* newmask,

sigset_t *
oldmask);

 

Mode takes one of the following values:

  • SIG_BLOCK--add the signals in newmask to the current signal m ask
  • SIG_UNBLOCK--remove the signals in newmask from the current signal mask
  • SIG_SETMASK--block only the signals in newmask


Retrieving Pending Signals

Blocked signals wait until the process is ready to receive them. Such signals are said to be pending and can be retrieved by calling sigpending():

int sigpending(sigset_t * pset);

 

About the Author

Danny Kalev Danny Kalev is a system analyst and software engineer with 13 years of experience, specializing in C++ and object-oriented analysis and design. He is a member of the ANSI C++ standardization committee and the author of ANSI/ISO C++ Professional Programmer's Handbook (Que, 1999, ISBN: 0789720221).


This article first appeared on DevX*. Reprinted with permission.