[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [LTP] fatal signal handling
On Mon, Sep 04, 2000 at 03:12:41PM -0500, Aaron Laffin wrote:
> We've avoided this problem on Irix through a mechanism where the default
> handler is reinstalled after a signal is received, meaning subsequent
> signals if not blocked go to the default handler. Irix signal() does
> this by default.
> I thought this also would be the case on Linux as the RedHat 6.2 man
> page for signal(2) seems to indicate the same:
> Unlike on BSD systems, signals under Linux are reset to
> their default behavior when raised. However, if you
> include <bsd/signal.h> instead of <signal.h> then signal
> is redefined as __bsd_signal and signal has the BSD seman<AD>
> tics. Both versions of signal are library routines built
> on top of sigaction(2).
This statement was true for libc5, but glibc 2.0 changed the default to
be BSD like.
(from the glibc FAQ):
* the `signal' function's behavior corresponds to the BSD semantic and
not the SysV semantic as it was in libc-5. The interface on all GNU
systems shall be the same and BSD is the semantic of choice. To use
the SysV behavior simply use `sysv_signal', or define _XOPEN_SOURCE.
See question 3.7 for details.
The official documentation for glibc is also not the man page, but the
info pages due to silly political reasons (that is a bit of an unfortunate
split in Linux -- kernel changes usually also do not cause a direct manpage
change). It would be probably better if the man pages were maintained in
the libc and kernel for 2 and 3 and any API changes required updates, but
that's unfortunately not the case currently.