SIGNAL(5)SIGNAL(5)NAMEsignal - 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 or a thread 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(2), sigqueue(3) or sigsend(2) 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)].
At the time of generation, the system will determine whether the signal
is directed at a process or a specific thread within that process.
Signals that are naturally associated with a particular thread, such as
hardware faults, are directed to the appropriate thread. This is usually
due to the signal being generated during the execution of the thread and,
moreover, in the context of executing that thread. Signals that are sent
to a process tend to be those that are generated asynchronously with
respect to the execution of the process. Signals generated by the kill
interface or sent as a result of a tty interrupt are examples of signals
directed at a process.
Each process may specify a system action to be taken in response to each
signal sent to it, called the signal's disposition. For multithreaded
processes, the disposition is shared by all threads in the process. 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(2), signal(2), signal(3B),
sigvec(3B) or sigset(2), 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 or thread when the
appropriate action for the 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 thread
[see sighold(2), sigblock(3) 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 or thread, the
signal remains pending until either it is unblocked or the signal's
disposition requests that the signal be ignored. Signals generated for
the process shall be delivered to exactly one of the threads within the
Page 1
SIGNAL(5)SIGNAL(5)
process. The thread must either be executing the sigwait function
selecting that signal or it must not be blocking delivery of the signal.
If there are no threads in a call to a sigwait function selecting that
signal, and if all threads within the process block delivery of the
signal, the signal shall remain pending of the process until either a
thread calls a sigwait function selecting that signal, a thread unblocks
delivery of that signal, or the action associated with the signal is set
to ignore the signal. If the signal disposition of a blocked signal
requests that the signal be ignored, and if that signal is generated for
the process or thread, the signal is discarded immediately upon
generation.
On IRIX, a pending signal is usually delivered when a thread returns from
the kernel. This happens at the end of a system call or at the end of a
hardware interrupt. Since the scheduling clock interrupt occurs at a
regular 10 msec interval, this means that the latency between the
generation of a signal and its delivery can never be more than 10 msec.
For real-time application(defined as process with high band non-degrading
priority), a generation of a signal always force an immediate signal
delivery.
Each thread has a signal mask that defines the set of signals currently
blocked from delivery to it [see sigprocmask(2) or pthread_sigmask(3P)].
The signal mask for a thread is initialized from the thread that created
it.
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:
Name Value Default Event
__________________________________________________________________________
SIGHUP 1 Exit Hangup [see termio(7)]
SIGINT 2 Exit Interrupt [see termio(7)]
SIGQUIT 3 Core Quit [see termio(7)]
SIGILL 4 Core Illegal Instruction
SIGTRAP 5 Core Trace, Breakpoint, Range Error
Divide by Zero, or Overflow Trap
SIGABRT 6 Core Abort
SIGEMT 7 Core Emulation Trap
SIGFPE 8 Core Arithmetic Exception
SIGKILL 9 Exit Killed
SIGBUS 10 Core Bus Error
SIGSEGV 11 Core Segmentation Fault
SIGSYS 12 Core Bad System Call
SIGPIPE 13 Exit Broken Pipe
SIGALRM 14 Exit Alarm Clock
Page 2
SIGNAL(5)SIGNAL(5)
SIGTERM 15 Exit Terminated
SIGUSR1 16 Exit User Signal 1
SIGUSR2 17 Exit User Signal 2
SIGCHLD 18 Ignore Child Status Changed
SIGPWR 19 Ignore Power Fail/Restart
SIGWINCH 20 Ignore Window Size Change
SIGURG 21 Ignore Urgent Socket Condition
SIGPOLL 22 Exit Pollable Event [see streamio(7)]
SIGIO 22 Exit input/output possible signal
SIGSTOP 23 Stop Stopped (signal)
SIGTSTP 24 Stop Stopped (user) [see termio(7)]
SIGCONT 25 Ignore Continued
SIGTTIN 26 Stop Stopped (tty input) [see termio(7)]
SIGTTOU 27 Stop Stopped (tty output) [see termio(7)]
SIGVTALRM 28 Exit Virtual Timer Expired
SIGPROF 29 Exit Profiling Timer Expired
SIGXCPU 30 Core CPU time limit exceeded [see getrlimit(2)]
SIGXFSZ 31 Core File size limit exceeded [see getrlimit(2)]
SIGCKPT 33 Ignore Checkpoint warning [see cpr(1)]
SIGRESTART 34 Ignore Restart warning [see cpr(1)]
SIGRTMIN 49 Exit POSIX 1003.1b SIGRTMIN
SIGRTMAX 64 Exit POSIX 1003.1b SIGRTMAX
IRIX supports all signal numbers between 0 and 64. All signals between 0
and 32 are currently used. POSIX 1003.1b reserves all signals between
SIGRTMIN and SIGRTMAX for real-time applications. Even though the kernel
does not use any signals between 35 and 64, signal number between 35 and
49 are not guaranteed to be available to user programs in future
releases. Further more, the default behavior for signals between 35 and
49 is to exit.
No signals beyond 32 are applicable to the Berkeley signal functions
because these functions use a fixed 32 bits signal mask as part the
programming interface.
Higher priority signals are delivered first when multiple unblocked
signals are pending in order to prioritize event notifications. On the
other hand, a lower priority signal can not preempt a higher priority
signal handler.
All signals between 0 and 32 are of equal priority but all are at higher
priority than signals between SIGRTMIN and SIGRTMAX. Within the range of
SIGRTMIN to SIGRTMAX, the lower the signal number the higher the priority
of that signal.
Using the signal(2), signal(3B), sigset(2), sigvec(3B) or sigaction(2)
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.
Page 3
SIGNAL(5)SIGNAL(5)
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
abnormally terminated with all the consequences outlined in
_exit(2).
Core When it gets the signal, the receiving process is to be
abnormally 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 thread is to execute the signal handler at the
specified address. Under IRIX, there are two ways a signal handler can be
delivered. If SA_SIGINFO is set in the field sa_flags of the sigaction_t
structure during a previous call to the sigaction(2) function for the
signal being delivered, the signal handler will be invoked as follows:
handler (int sig, siginfo_t *sip, ucontext_t *up);
otherwise the signal handler will be invoked as follows:
handler (int sig, int code, struct sigcontext *sc);
Where handler is the specified signal handler function-name. Due to
historic implementations, signal handlers have been defined with zero,
one, or three parameters. To avoid source incompatibilities, in C, the
prototype for the signal handler has intentionally been left empty. C++
requires a prototype, so a compromise must be made. C++ user's should
cast their handler to the type SIG_PF in order to be portable.
Please see siginfo(5) and ucontext(5) for more details on the meanings of
the passed in parameters of the first form. The second form is the
default system behavior.
In the second form, code is valid only in the following cases:
Condition Signal Code
User breakpoint SIGTRAP BRK_USERBP
Page 4
SIGNAL(5)SIGNAL(5)
User breakpoint SIGTRAP BRK_SSTEPBP
Integer overflow SIGFPE BRK_OVERFLOW
Divide by zero SIGFPE BRK_DIVZERO
Multiply overflow SIGFPE BRK_MULOVF
Invalid virtual address SIGSEGV EFAULT
Read-only address SIGSEGV EACCES
Read beyond mapped object SIGSEGV ENXIO
Autogrow for file failed SIGSEGV ENOSPC
Automatic memory lock failed SIGSEGV ENOMEM
Too many mappings to a page SIGBUS E2BIG
Integer divide by zero, multiply overflow, integer overflow, and range
errors are special cases. If the binary is not an IRIX 4 binary and a
signal handler is installed for SIGFPE then the SIGFPE handler is called,
otherwise SIGTRAP is called. This behavior is included to keep older IRIX
4 and IRIX 5 binaries working, however the correct way to code a handler
is to use SIGFPE.
The third argument sc of the second form is a pointer to a struct
sigcontext (defined in <sys/signal.h>) that contains the processor
context at the time of the signal.
When the signal handler returns, the receiving thread 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 signal(3B), sigset(2),
sigvec(3B) or sigaction(2) 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 sigrelse(2), sigprocmask(2), and
pthread_sigmask(3P)].
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 thread 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.
Whenever a process receives a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU
signal, regardless of its disposition, any pending SIGCONT signal are
discarded. Further more, the process will not act upon any delivered
signals other than SIGKILL until a SIGCONT is received.
Page 5
SIGNAL(5)SIGNAL(5)
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.
When a signal is delivered to a thread, if the action of that signal
specifies termination, stop, or continue, all the threads in the process
shall be terminated, stopped, or continued, respectively.
Processes which are blocked via a blockproc system call will unblock if
they receive a signal which is fatal (i.e., a non-job-control signal
which the are NOT catching), but will still be stopped if the job of
which they are a part is stopped. Only upon restart will they die. Any
non-fatal signals received by a blocked process will NOT cause the
process to be unblocked (an unblockproc(2) or unblockprocall(2) system
call is necessary).
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, sigvec
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.
A call to signal cancels a pending signal sig except for a pending
SIGKILL signal.
A call to sigset with a signal handler other than SIG_IGN will
automatically allow pending signals for the set signal to come in.
SEE ALSOexit(2), getrlimit(2), intro(2), kill(2), pause(2), pthread_kill(3P),
pthread_sigmask(3P), sigaction(2), sigaltstack(2), signal(2), sigset(2),
signal(3B), sigprocmask(2), sigsend(2), sigqueue(3), sigsuspend(2),
wait(2), sigsetops(3C), siginfo(5), ucontext(5)
Page 6
