Karel Zak wrote:
On Wed, Jul 30, 2008 at 03:55:13PM +0200, maximilian attems wrote:
s/signal/bsd_signal/ to make it evident which semantics
are expected.
(guy, be happy that Ulrich Drepper is not around:-)
why not sigaction(2) ?
man bsd_signal:
On modern Linux systems, bsd_signal() and signal(2)
are equivalent.
Do you mean that klibc signal() is different from glibc?
I dropped signal() from klibc entirely, because I didn't like the
ambiguity between SysV and BSD semantics. "On modern Linux systems"
refer to the unilateral decision of glibc to switch from signal()
meaning sysv_signal() to signal() meaning bsd_signal().
This *did* turn out to be a reasonable thing to do, as most code out
there that uses unadorned signal() appears to be BSD-derived.
I specifically stated in the README for klibc that "if you want signal,
compile with -Dsignal=bsd_signal or -Dsignal=sysv_signal".
At this point, sysv_signal() seems to largely have disappeared from the
Linux universe, even though the system call still implements it.
However, stylistically speaking, I still think signal() is quite the
time bomb to have lying around, and that bsd_signal() [which *IS* in
POSIX!] is a better choice, alternatively the following function:
void (*xsignal(int sig, void (*func)(int), int flags))(int)
{
struct sigaction act, oact;
act.sa_handler = func;
act.sa_flags = flags;
sigemptyset(&act.sa_mask);
sigaddset(&act.sa_mask, sig);
if (sigaction(sig, &act, &oact) == -1)
return SIG_ERR;
return oact.sa_handler;
}
... which is equivalent to bsd_signal(foo, bar) if called as
xsignal(foo, bar, SA_RESTART) or sysv_signal(foo, bar) if called as
xsignal(foo, bar, SA_RESETHAND).
Now, for simple "crap out and die" signal handler, classical signal()
does work, but for the vast majority of all cases, it's simply too
ambiguous, and is a portability timebomb.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
