signal — ANSI C signal handling
#include <signal.h> typedef void (*sighandler_t)(int);
sighandler_t signal( |
int | signum, |
sighandler_t | handler) ; |
The behaviour of signal
()
varies across Unix versions, and has also varied historically
across different versions of Linux. Avoid its use: use sigaction(2) instead. See
Portability
below.
signal
() sets the
disposition of the signal signum
to handler
, which is either
SIG_IGN
, SIG_DFL
, or the address of a
programmer-defined function (a "signal handler"),
If the signal signum
is delivered to the
process, then one of the following happens:
If the disposition is set to SIG_IGN
, then the signal is
ignored.
If the disposition is set to SIG_DFL
, then the default action
associated with the signal (see signal(7))
occurs.
If the disposition is set to a function, then first
either the disposition is reset to SIG_DFL
, or the signal is blocked
(see Portability
below), and
then handler
is
called with argument signum
. If invokation of
the handler caused the signal to be blocked, then the
signal is unblocked upon return from the handler.
The signals SIGKILL
and
SIGSTOP
cannot be caught or
ignored.
The effects of signal
() in a
multi-threaded process are unspecified.
According to POSIX, the behaviour of a process is
undefined after it ignores a SIGFPE
, SIGILL
, or SIGSEGV
signal that was not generated by
kill(2) or the raise(3). Integer division
by zero has undefined result. On some architectures it will
generate a SIGFPE
signal. (Also
dividing the most negative integer by −1 may generate
SIGFPE
.) Ignoring this signal
might lead to an endless loop.
See sigaction(2) for details on
what happens when SIGCHLD
is
set to SIG_IGN
.
See signal(7) for a list of the async-signal-safe functions that can be safely called inside from inside a signal handler.
The use of sighandler_t
is a GNU
extension. Various versions of libc predefine this type;
libc4 and libc5 define SignalHandler
, glibc defines
sig_t
and, when
_GNU_SOURCE
is defined, also
sighandler_t
.
The original Unix signal
()
would reset the handler to SIG_DFL, and System V (and the
Linux kernel and libc4,5) does the same. On the other hand,
BSD does not reset the handler, but blocks new instances of
this signal from occurring during a call of the handler.
The glibc2 library follows the BSD behaviour.
If one on a libc5 system includes <bsd/signal.h>
instead of <signal.h>
then
signal
() is redefined as
__bsd_signal
() and
signal
() has the BSD
semantics. This is not recommended.
If one on a glibc2 system defines a feature test macro
such as _XOPEN_SOURCE
or uses
a separate sysv_signal(3) function,
one obtains classical behaviour. This is not
recommended.
kill(1), alarm(2), kill(2), pause(2), sigaction(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), bsd_signal(3), killpg(3), raise(3), siginterrupt(3), sigsetops(3), sigvec(3), sysv_signal(3), feature_test_macros(7), signal(7)
|