signalfd.2: Fix description of fork() semantics

The page text described the semantics of the initial
implementation of signalfd().  These were changed early on,
but the man page wasn't updated.

Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Reviewed-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2009-01-13 02:12:09 +13:00
parent 59190704db
commit 98895092a0
1 changed files with 5 additions and 9 deletions

View File

@ -16,7 +16,7 @@
.\" Foundation, Inc., 59 Temple Place, Suite 330, Boston,
.\" MA 02111-1307 USA
.\"
.TH SIGNALFD 2 2008-10-20 Linux "Linux Programmer's Manual"
.TH SIGNALFD 2 2009-01-13 Linux "Linux Programmer's Manual"
.SH NAME
signalfd \- create a file descriptor for accepting signals
.SH SYNOPSIS
@ -219,14 +219,10 @@ for details.
After a
.BR fork (2),
the child inherits a copy of the signalfd file descriptor.
The file descriptor refers to the same underlying
file object as the corresponding descriptor in the parent,
and
.BR read (2)s
in the child will return information about signals generated
for the parent
(the process that created the object using
.BR signalfd ()).
A
.BR read (2)
from the file descriptor in the child will return information
about signals queued to the child.
.SS execve(2) semantics
Just like any other file descriptor,
a signalfd file descriptor remains open across an