ptg1080515910
Signals
10.1 Introduction
Signals aresoftwareinterrupts. Most nontrivial application programs need to deal with
signals. Signals provide a way of handling asynchronous events—for example, a user
at a terminal typing the interrupt key to stop a program or the next program in a
pipeline terminating prematurely.
Signals have been provided since the early versions of the UNIX System, but the
signal model provided with systems such as Version 7 was not reliable. Signals could
get lost, and it was difficult for a process to turn offselected signals when executing
critical regions of code. Both 4.3BSD and SVR3 made changes to the signal model,
adding what arecalledreliable signals.But the changes made by Berkeley and AT&T
wereincompatible. Fortunately,POSIX.1 standardized the reliable-signal routines, and
that is what we describe here.
In this chapter, we start with an overview of signals and a description of what each
signal is normally used for.Then we look at the problems with earlier implementations.
It is often important to understand what is wrong with an implementation beforeseeing
how to do things correctly.This chapter contains numerous examples that arenot
entirely correct and a discussion of the defects.10.2 Signal Concepts
First, every signal has a name. These names all begin with the three charactersSIG.For
example,SIGABRTis the abort signal that is generated when a process calls theabort
function. SIGALRMis the alarm signal that is generated when the timer set by the
alarmfunction goes off. Version 7 had 15 different signals; SVR4 and 4.4BSD both had
31 different signals. FreeBSD 8.0 supports 32 different signals. Mac OS X 10.6.8 and313