kern/19402: Signals 127 and 128 cannot be detected in wait4()
interface
Jilles Tjoelker
jilles at stack.nl
Sun Apr 29 22:50:11 UTC 2012
The following reply was made to PR kern/19402; it has been noted by GNATS.
From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, netch at segfault.kiev.ua
Cc: bde at freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
interface
Date: Mon, 30 Apr 2012 00:46:19 +0200
> [problems with signals 127 and 128]
First, note that "clean" programs cannot use signals 127 and 128 because
they do neither have a SIG* constant nor are in the range SIGRTMIN to
SIGRTMAX. Therefore, I think it is inappropriate to make large changes
to make them work. It suffices if wait4() and other interfaces cannot
cause confusion.
Because sh returns exit status 128+sig for signal sig, signal 128 cannot
be represented in an 8-bit exit status and would have to be aliased to
another signal if it is kept.
The suggestion to modify wait4() ABI seems inappropriate for that
reason.
Another option is to modify the highest signal number accepted by
interfaces (while leaving the size of sigset_t and the like unchanged).
This effectively removes signals 127 and 128 from the system. One
problem results when having posix_spawn() from an old libc reset all
signals to default (by passing posix_spawnattr_setsigdefault() a
sigfillset()'ed sigset_t and enabling the POSIX_SPAWN_SETSIGDEF flag in
the posix_spawnattr_t). It will then attempt to set all signals from 1
to 128 to the default action and fail the entire spawn if sigaction()
fails. This could be allowed by having certain calls (such as
sigaction() with SIG_DFL) return success without doing anything for
signals 127 and 128. This is likely to get messy.
Alternatively, the default action for signals 127 and 128 could be
changed to ignore (like SIGCHLD, SIGURG and SIGINFO), so that no process
may terminate because of them. Processes can still send the signals and
set handlers for them. Apart from the obvious effect that the process
will not terminate when it receives such a signal without handling or
masking it, FreeBSD also discards ignored signals even when they are
masked (POSIX permits this). This could lead to unexpected results if a
process is using sigwait() or a similar function.
Yet another approach would modify the wait4() system call, changing
signals 127 and 128 to something that does not cause confusion. This
seems ugly.
--
Jilles Tjoelker
More information about the freebsd-bugs
mailing list