[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.