signal — ANSI C signal handling
#include <signal.h> typedef void (*sighandler_t)(int);
sighandler_t
signal( |
int signum, |
sighandler_t handler); |
The behavior 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 invocation 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
multithreaded process are unspecified.
According to POSIX, the behavior of a process is undefined
after it ignores a SIGFPE,
SIGILL, or SIGSEGV signal that was not generated by
kill(2) or 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 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. Without use of such a type, the
declaration of signal() is the
somewhat harder to read:
void(*signal(int signum,void (*handler)(int)) ) (int);
The only portable use of signal() is to set a signal's disposition
to SIG_DFL or SIG_IGN. The semantics when using
signal() to establish a
signal handler vary across systems (and POSIX.1 explicitly
permits this variation); do not
use it for this purpose.
POSIX.1 solved the portability mess by specifying
sigaction(2), which
provides explicit control of the semantics when a signal
handler is invoked; use that interface instead of
signal().
In the original UNIX systems, when a handler that was
established using signal()
was invoked by the delivery of a signal, the disposition of
the signal would be reset to SIG_DFL, and the system did not block
delivery of further instances of the signal. System V also
provides these semantics for signal(). This was bad because the signal
might be delivered again before the handler had a chance to
reestablish itself. Furthermore, rapid deliveries of the
same signal could result in recursive invocations of the
handler.
BSD improved on this situation by changing the semantics
of signal handling (but, unfortunately, silently changed
the semantics when establishing a handler with signal()). On BSD, when a signal handler
is invoked, the signal disposition is not reset, and
further instances of the signal are blocked from being
delivered while the handler is executing.
The situation on Linux is as follows:
The kernel's signal() system call provides
System V semantics.
By default, in glibc 2 and later, the signal() wrapper function does not
invoke the kernel system call. Instead, it calls
sigaction(2) using
flags that supply BSD semantics. This default
behavior is provided as long as the _BSD_SOURCE feature test macro is
defined. By default, _BSD_SOURCE is defined; it is also
implicitly defined if one defines _GNU_SOURCE, and can of course be
explicitly defined.
On glibc 2 and later, if the _BSD_SOURCE feature test macro is
not defined, then signal() provides System V
semantics. (The default implicit definition of
_BSD_SOURCE is not
provided if one invokes gcc(1) in one of its
standard modes (−std=xxx or −ansi) or defines various other
feature test macros such as _POSIX_SOURCE, _XOPEN_SOURCE, or _SVID_SOURCE; see feature_test_macros(7).)
The signal()
function in Linux libc4 and libc5 provide System V
semantics. If one on a libc5 system includes
<bsd/signal.h> instead of <signal.h> then signal() provides BSD
semantics.
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2), sigprocmask(2), sigsuspend(2), bsd_signal(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3), sigvec(3), sysv_signal(3), signal(7)
This page is part of release 3.34 of the Linux man-pages project. A
description of the project, and information about reporting
bugs, can be found at http://man7.org/linux/man-pages/.
|
Copyright (c) 2000 Andries Brouwer <aebcwi.nl> and Copyright (c) 2007 Michael Kerrisk <mtk.manpagesgmail.com> and Copyright (c) 2008, Linux Foundation, written by Michael Kerrisk <mtk.manpagesgmail.com> based on work by Rik Faith <faithcs.unc.edu> and Mike Battersby <mikestarbug.apana.org.au>. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Since the Linux kernel and libraries are constantly changing, this manual page may be incorrect or out-of-date. The author(s) assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. The author(s) may not have taken the same level of care in the production of this manual, which is licensed free of charge, as they might when working professionally. Formatted or processed versions of this manual, if unaccompanied by the source, must acknowledge the copyright and authors of this work. Modified 2004-11-19, mtk: added pointer to sigaction.2 for details of ignoring SIGCHLD 2007-06-03, mtk: strengthened portability warning, and rewrote various sections. 2008-07-11, mtk: rewrote and expanded portability discussion. |