signal — ANSI C signal handling
#include <signal.h> typedef void (*sighandler_t)(int);
sighandler_t signal( |
int | signum, |
sighandler_t | handler) ; |
The signal
() system call
installs a new signal handler for the signal with number
signum
. The signal
handler is set to handler
which may be a user
specified function, or either SIG_IGN
or SIG_DFL
.
Upon arrival of a signal with number signum
the following happens.
If the corresponding handler is set to SIG_IGN
, then the signal is ignored. If the
handler is set to SIG_DFL
, then
the default action associated with the signal (see signal(7)) occurs. Finally,
if the handler is set to a function handler
then first either the
handler is reset to SIG_DFL or an implementation-dependent
blocking of the signal is performed, and then handler
is called with argument
signum
.
Using a signal handler function for a signal is called
"catching the signal". The signals SIGKILL
and SIGSTOP
cannot be caught or ignored.
The signal
() function
returns the previous value of the signal handler, or
SIG_ERR
on error.
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
function,
one obtains classical behaviour. This is not recommended.
Trying to change the semantics of this call using defines
and includes is not a good idea. It is better to avoid
signal
() altogether, and use
sigaction(2) instead.
The effects of this call 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
the kill(2) or the raise(3) functions. 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
.
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), sigsetops(3), sigvec(3), sysv_signal(3), feature_test_macros(7), signal(7)
|