Section 1.6. Signals

1.6. Signals

UNIX systems have provided a process signaling mechanism from the earliest implementations. The signal facility provides a method of interrupting a process or thread within a process as a result of a specific event. The events that trigger signals can be directly related to the current instruction stream. Such signals, referred to as synchronous signals, originate as hardware trap conditions arising from illegal address references (segmentation violation), illegal math operations (floating point exceptions), and the like.

The system also implements asynchronous signals, which result from an external event not necessarily related to the current instruction stream. Examples of asynchronous signals include job control signals and the sending of a signal from one process or thread to another. For example, sending a kill signal to terminate a process.

For each possible signal, a process can establish one of three possible signal dispositions that define what action, if any, will be taken when the signal is received. Most signals can be ignored; a signal can be caught and a process-specific signal handler invoked; or a process can permit the default action to be taken. Every signal has a predefined default action, for example, terminate the process. Solaris OS provides a set of programming interfaces that allow signals to be masked or a specific signal handler to be installed.

The traditional signal model was built on the concept of a process having a single execution stream at any time. The Solaris kernel's multithreaded process architecture accommodates multiple threads of execution within a process, meaning that a signal can be directed to a specific thread. The disposition and handlers for signals is the same for every thread in a multithreaded process. However, the Solaris model permits signals to be masked at the thread level, so different threads within the process can have different signals masked. (Masking is a means of blocking a signal from being delivered.)