Signal handling has evolved on UNIX. Some UNIX's (including SVR4) let you block them, hold them, find out which PID and UID sent them, or determine why they were sent. Unreliable signal handling was the only kind available on older systems and some functions such as signal(3C) may provide only unreliable signals. Signals could not be queued, blocked, or if blockable then another signal could slip through. When the only purpose for handling a signal is to clean up before terminating this is not quite so bad. Many textbooks discuss only unreliable signals and have flawed code.

There are three actions that a process can take on a signal. The signal can be default processed (SIG_DFL), ignored (SIG_IGN) or caught. The default action (SIG_DFL) on receiving most signals is termination of the process. Signals could instead be ignored (SIG_IGN), but this is reasonable for only certain signals and even then not always. A signal is caught if a signal handler function has been installed. The action in this case is to call the signal handler. This is fraught with problems, mostly because signals can arrive at awkward times and race conditions may occur.

1. Deal with the signal in the signal handler, then return or exit.
2. Set a flag then return. In the main code, test for the flag at a convenient time. The flag must be declared volatile as it can change value at any time.
3. Use longjmp(3C) or better siglongjmp(3C) to jump back to a previous execution point. siglongjmp is essentially a non-local go to; it unwinds the stack. At some point in the program call sigsetjmp, which marks the current point of execution and stores the signal mask. When siglongjmp is called, processing returns to the sigsetjmp point. There are several restrictions, including that you cannot siglongjmp to a sigsetjmp point once the function containing the sigsetjmp has returned, so change the signal handler before returning from the function. All register and non-volatile auto variables at the sigsetjmp point have undefined values when siglongjmp is taken.

Suppose a signal arrives in the middle of a malloc. This is very awkward because chaos will result if the signal handler also calls malloc. So it is unsafe to use malloc in a handler. The same applies to any other library functions that uses static data structures or that calls malloc. This includes all stdio functions and many other library functions. A further problem is that if processing is to be resumed, then the malloc must be resumed, so siglongjmp should not be used in the handler for this signal. Exiting or setting a flag is the only reasonable solution.

If the handler returns, processing resumes at the point of interruption. Depending on the signal this can be undesirable. For example, a return in connection with SIGFPE will lead to an immediate second SIGFPE unless you patch up the problem. Patching is very difficult but even if possible, will require some dirty machine dependent method. Rather than returning from the handler, a siglongjmp or exit is more reasonable in this case.

A process can generate signals in several ways. Of course it can unintentional generate them by attempting illegal hardware operations, such as by dividing by zero, or by attempting to execute malformed machine instructions. A process can generate signals intentional with: kill(2), raise(3C) (sends the signal to itself), alarm(2) (which starts a timer). Related to these is pause(2) or better yet sigsuspend(2) which suspends a process until the next signal is delivered. Note: Making a process ``sleep'' on a multitasking system by using a time consuming loop is very poor manners. Instead use an alarm and sigsuspend or sleep(1) or sleep(3C) which in turn use alarm and pause.

The basic but unreliable signal function is signal(3C). Suppose we define:

Signals are especially hard to handle in system calls. Calls that involve waits such as open(2), read(2), and write(2) on slow devices (terminal and pipes but not disks) that could block for long periods, if interrupted will return with the error EINTR and are not restarted by default (but modern UNIX's can transparently restart them). Your program needs to restart them in this case. A not completely satisfactory alternative is to block signals while doing these, however, your program becomes temporarily uninterruptable! This affects stdio functions like getchar( ) since EOF is returned even though a ``real'' EOF has not yet been seen; set a flag in the handler and then test this flag to see if the EOF was caused by a signal.

For a related example, consider:

As a first step, sigset_t sset declares a signal set (mask) called sset. Use sigemptyset(&sset) or sigfillset(&sset) to exclude all or include all signals in the set. Then include or exclude each desired signal, signo, one at a time with sigaddset(&sset, signo) or sigdelset(&sset, signo). To test if signo is in a set use: sigismember(&sset, signo).

The signal mask for a process is altered with sigprocmask(how, &sset, &oldsset) which can be used to change which signals are blocked. how determines the interpretation of sset. A SIG_BLOCK or SIG_UNBLOCK indicates that sset specifies additional signals to block or unblock. If how is SIG_SETMASK then sset is the new mask. If &oldsset is not NULL then the old mask is returned through it. If &sset is NULL then how is not used and no change is made to the current mask.

sigpending(&sset) tells which signals are pending. To test if SIGINT is pending: