NAME

signal − base signals

SYNOPSIS

#include <signal.h>

DESCRIPTION

A signal is an asynchronous notification of an event.  A signal is said to be generated for (or sent to) a process when the event associated with that signal first occurs. Examples of such events include hardware faults, timer expiration and terminal activity, as well as the invocation of the kill or sigsend system calls.  In some circumstances, the same event generates signals for multiple processes.  A process may request a detailed notification of the source of the signal and the reason why it was generated [see siginfo(5)]. 

Each process may specify a system action to be taken in response to each signal sent to it, called the signal’s disposition.  The set of system signal actions for a process is initialized from that of its parent.  Once an action is installed for a specific signal, it usually remains installed until another disposition is explicitly requested by a call to either sigaction, signal or sigset, or until the process execs [see sigaction(2) and signal(2)].  When a process execs, all signals whose disposition has been set to catch the signal will be set to SIG_DFL.  Alternatively, a process may request that the system automatically reset the disposition of a ­signal to SIG_DFL after it has been caught [see sigaction(2) and signal(2)]. 

A signal is said to be delivered to a process when the appropriate action for the process and signal is taken.  During the time between the generation of a signal and its delivery, the signal is said to be pending [see sigpending(2)].  Ordinarily, this interval cannot be detected by an application. However, a signal can be blocked from delivery to a process [see signal(2) and sigprocmask(2)].  If the action associated with a blocked signal is anything other than to ignore the signal, and if that signal is generated for the process, the signal remains pending until either it is unblocked or the signal’s disposition requests that the signal be ignored.  If the signal disposition of a blocked signal requests that the signal be ignored, and if that signal is generated for the process, the signal is discarded immediately upon generation. 

Each process has a signal mask that defines the set of signals currently blocked from delivery to it [see sigprocmask(2)].  The signal mask for a process is initialized from that of its parent. 

The determination of which action is taken in response to a signal is made at the time the signal is delivered, allowing for any changes since the time of generation.  This determination is independent of the means by which the signal was ­originally generated. 

The signals currently defined in signal.h are as follows:

Using the signal, sigset or sigaction system call, a process may specify one of three dispositions for a signal: take the default action for the signal, ignore the signal, or catch the signal. 

Default Action: SIG_DFL

A disposition of SIG_DFL specifies the default action.  The default action for each signal is listed in the table above and is selected from the following:

­Exit When it gets the signal, the receiving process is to be terminated with all the consequences outlined in exit(2). 

­Core When it gets the signal, the receiving process is to be terminated with all the consequences outlined in exit(2).  In addition, a “core image” of the process is constructed in the current working directory. 

­Stop When it gets the signal, the receiving process is to stop. 

­Ignore When it gets the signal, the receiving process is to ignore it.  This is identical to setting the disposition to SIG_IGN. 

Ignore Signal: SIG_IGN

A disposition of SIG_IGN specifies that the signal is to be ignored. 

Catch Signal: function address

A disposition that is a function address specifies that, when it gets the signal, the receiving process is to execute the signal handler at the specified address.  Normally, the signal handler is passed the signal number as its only argument; if the disposition was set with the sigaction function however, additional arguments may be requested [see sigaction(2)].  When the signal handler returns, the receiving process resumes execution at the point it was interrupted, unless the signal handler makes other arrangements.  If an invalid function address is specified, results are undefined. 

If the disposition has been set with the sigset or sigaction function, the signal is automatically blocked by the system while the signal catcher is executing.  If a longjmp [see setjmp(3C)] is used to leave the signal catcher, then the signal must be explicitly unblocked by the user [see signal(2) and sigprocmask(2)]. 

If execution of the signal handler interrupts a blocked system call, the handler is executed and the interrupted system call returns a −1 to the calling process with errno set to EINTR. However, if the SA_RESTART flag is set the system call will be transparently restarted. 

NOTES

The dispositions of the SIGKILL and SIGSTOP signals cannot be altered from their default values.  The system generates an error if this is attempted. 

The SIGKILL and SIGSTOP signals cannot be blocked.  The system silently enforces this restriction. 

If a process receives a SIGSEGV or SIGBUS resulting from an instruction access while it is blocking or ignoring that signal, the system will set the process’s handler to SIG_DFL before delivering the signal, causing the process to terminate with a core file. 

Signals resulting from machine exceptions cannot be blocked or ignored.  The system silently ignores attempts to do so.  The signals that result from machine exceptions are SIGSEGV, SIGILL, SIGBUS, SIGTRAP, and SIGFPE.  The behavior of a process that generates a machine exception (e.g. floating point exception or bus error) that gives rise to a signal that is blocked or ignored is specifically undefined and not portable.  The behavior may change in future releases or on different processor boards.  The behavior of SIGSEGV and SIGBUS remains as described above (reset to SIG_DFL and deliver the signal). 

Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal, regardless of its disposition, any pending SIGCONT signal are discarded. 

Whenever a process receives a SIGCONT signal, regardless of its disposition, any pending SIGSTOP, SIGTSTP, SIGTTIN, and SIGTTOU signals is discarded.  In addition, if the process was stopped, it is continued. 

SIGPOLL is issued when a file descriptor corresponding to a STREAMS [see intro(2)] file has a “selectable” event pending.  A process must specifically request that this signal be sent using the I_SETSIG ioctl call.  Otherwise, the process will never receive SIGPOLL. 

If the disposition of the SIGCHLD signal has been set with signal or sigset, or with sigaction and the SA_NOCLDSTOP flag has been specified, it will only be sent to the calling process when its children exit; otherwise, it will also be sent when the calling process’s children are stopped or continued due to job control. 

The name SIGCLD is also defined in this header file and identifies the same signal as SIGCHLD. SIGCLD is provided for backward compatibility, new applications should use SIGCHLD.  The disposition of signals that are inherited as SIG_IGN should not be changed. 

SEE ALSO

exit(2), getrlimit(2), intro(2), kill(2), pause(2), sigaction(2), sigaltstack(2), signal(2), sigprocmask(2), sigsend(2), sigsuspend(2), wait(2), sigsetops(3C), siginfo(5), ucontext(5)