mirror of https://github.com/mkerrisk/man-pages
Rewrote and expnaded discussion of portability.
This commit is contained in:
parent
b66cb8b5c4
commit
98e1ece326
130
man2/signal.2
130
man2/signal.2
|
@ -25,10 +25,11 @@
|
||||||
.\"
|
.\"
|
||||||
.\" Modified 2004-11-19, mtk:
|
.\" Modified 2004-11-19, mtk:
|
||||||
.\" added pointer to sigaction.2 for details of ignoring SIGCHLD
|
.\" added pointer to sigaction.2 for details of ignoring SIGCHLD
|
||||||
.\" 2007-06-03, mtk: strengthened portability warning, and rerote
|
.\" 2007-06-03, mtk: strengthened portability warning, and rewrote
|
||||||
.\" various sections.
|
.\" various sections.
|
||||||
|
.\" 2008-07-11, mtk: rewrote and expanded portability discussion.
|
||||||
.\"
|
.\"
|
||||||
.TH SIGNAL 2 2007-06-03 "Linux" "Linux Programmer's Manual"
|
.TH SIGNAL 2 2008-07-11 "Linux" "Linux Programmer's Manual"
|
||||||
.SH NAME
|
.SH NAME
|
||||||
signal \- ANSI C signal handling
|
signal \- ANSI C signal handling
|
||||||
.SH SYNOPSIS
|
.SH SYNOPSIS
|
||||||
|
@ -134,7 +135,7 @@ is set to
|
||||||
See
|
See
|
||||||
.BR signal (7)
|
.BR signal (7)
|
||||||
for a list of the async-signal-safe functions that can be
|
for a list of the async-signal-safe functions that can be
|
||||||
safely called inside from inside a signal handler.
|
safely called from inside a signal handler.
|
||||||
.PP
|
.PP
|
||||||
The use of
|
The use of
|
||||||
.I sighandler_t
|
.I sighandler_t
|
||||||
|
@ -147,37 +148,112 @@ and, when
|
||||||
.B _GNU_SOURCE
|
.B _GNU_SOURCE
|
||||||
is defined, also
|
is defined, also
|
||||||
.IR sighandler_t .
|
.IR sighandler_t .
|
||||||
.SS Portability
|
Without use of such a type, the declaration of
|
||||||
The original Unix
|
|
||||||
.BR signal ()
|
.BR signal ()
|
||||||
would reset the handler to
|
is the somewhat harder to read:
|
||||||
.BR SIG_DFL ,
|
.in +4n
|
||||||
and System V
|
.nf
|
||||||
(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 behavior.
|
|
||||||
|
|
||||||
|
.BI "void ( *" signal "(int " signum ", void (*" handler ")(int)) ) (int);"
|
||||||
|
.fi
|
||||||
|
.in
|
||||||
|
.SS Portability
|
||||||
|
The only portable use of
|
||||||
|
.BR signal ()
|
||||||
|
is to set a signal's disposition to
|
||||||
|
.BR SIG_DFL
|
||||||
|
or
|
||||||
|
.BR SIG_IGN .
|
||||||
|
The semantics when using
|
||||||
|
.BR signal ()
|
||||||
|
to establish a signal handler vary across systems
|
||||||
|
(and POSIX.1 explicitly permits this variation);
|
||||||
|
.B do not use it for this purpose.
|
||||||
|
|
||||||
|
POSIX.1 solved the portability mess by specifying
|
||||||
|
.BR sigaction (2),
|
||||||
|
which provides explicit control of the semantics when a
|
||||||
|
signal handler is invoked; use that interface instead of
|
||||||
|
.BR signal ().
|
||||||
|
|
||||||
|
In the original Unix systems, when a handler that was established using
|
||||||
|
.BR signal ()
|
||||||
|
was invoked by the delivery of a signal,
|
||||||
|
the disposition of the signal would be reset to
|
||||||
|
.BR SIG_DFL ,
|
||||||
|
and the system did not block delivery of further instances of the signal.
|
||||||
|
System V also provides these semantics for
|
||||||
|
.BR 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
|
||||||
|
.BR 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:
|
||||||
|
.IP * 2
|
||||||
|
The kernel's
|
||||||
|
.BR signal ()
|
||||||
|
system call provides System V semantics.
|
||||||
|
.IP *
|
||||||
|
By default, in glibc 2 and later, the
|
||||||
|
.BR signal ()
|
||||||
|
wrapper function does not invoke the kernel system call.
|
||||||
|
Instead, it calls
|
||||||
|
.BR sigaction (2)
|
||||||
|
using flags that supply BSD semantics.
|
||||||
|
This default behavior is provided as long as the
|
||||||
|
.B _BSD_SOURCE
|
||||||
|
feature test macro is defined.
|
||||||
|
By default,
|
||||||
|
.B _BSD_SOURCE
|
||||||
|
is defined;
|
||||||
|
it is also implicitly defined if one defines
|
||||||
|
.BR _GNU_SOURCE ,
|
||||||
|
and can of course be explicitly defined.
|
||||||
|
.sp
|
||||||
|
On glibc 2 and later, if the
|
||||||
|
.B _BSD_SOURCE
|
||||||
|
feature test macro is not defined, then
|
||||||
|
.BR signal ()
|
||||||
|
provides System V semantics.
|
||||||
|
(The default implicit definition of
|
||||||
|
.B _BSD_SOURCE
|
||||||
|
is not provided if one invokes
|
||||||
|
.BR gcc (1)
|
||||||
|
in one of its standard modes
|
||||||
|
.RI ( -std=xxx " or " -ansi )
|
||||||
|
or defines various other feature test macros such as
|
||||||
|
.BR _POSIX_SOURCE ,
|
||||||
|
.BR _XOPEN_SOURCE ,
|
||||||
|
or
|
||||||
|
.BR _SVID_SOURCE ;
|
||||||
|
see
|
||||||
|
.BR feature_test_macros (7).)
|
||||||
|
.\"
|
||||||
|
.\" System V semantics are also provided if one uses the separate
|
||||||
|
.\" .BR sysv_signal (3)
|
||||||
|
.\" function.
|
||||||
|
.IP *
|
||||||
|
The
|
||||||
|
.BR signal ()
|
||||||
|
function in Linux libc4 and libc5 provide System V semantics.
|
||||||
If one on a libc5 system includes
|
If one on a libc5 system includes
|
||||||
.I <bsd/signal.h>
|
.I <bsd/signal.h>
|
||||||
instead of
|
instead of
|
||||||
.I <signal.h>
|
.IR <signal.h> ,
|
||||||
then
|
then
|
||||||
.BR signal ()
|
.BR signal ()
|
||||||
is redefined as
|
provides BSD semantics.
|
||||||
.BR __bsd_signal ()
|
|
||||||
and
|
|
||||||
.BR signal ()
|
|
||||||
has the BSD semantics.
|
|
||||||
This is not recommended.
|
|
||||||
|
|
||||||
If one on a glibc2 system defines a feature test
|
|
||||||
macro such as
|
|
||||||
.B _XOPEN_SOURCE
|
|
||||||
or uses a separate
|
|
||||||
.BR sysv_signal (3)
|
|
||||||
function, one obtains classical behavior.
|
|
||||||
This is not recommended.
|
|
||||||
.SH "SEE ALSO"
|
.SH "SEE ALSO"
|
||||||
.BR kill (1),
|
.BR kill (1),
|
||||||
.BR alarm (2),
|
.BR alarm (2),
|
||||||
|
|
Loading…
Reference in New Issue