Board index Linux

Signal handlers are not reset after signal delivery

Signal handlers are not reset after signal delivery

Post by Kartik Gopala » Mon, 17 Aug 1998 04:00:00



The man page for signal says

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

However I tried the following simple program and found that if I install
a signal handler once, it remains installed over multiple deliveries of
the same signal. i.e. the signal does not get  reset to its default
behaviour when raised.

#include <stdio.h>
#include <signal.h>

void  handler( int x) {

        printf( "Got the signal\n");

Quote:}

main() {

        char c;
        signal(28, handler);

        sleep(3600);

        printf( "Woke up\n");
        sleep(3600);

Quote:}

and the I did 'kill -28 <pid>' twice. Both the times I got the
message from signal handler.

Can anyone help explain this contradiction or am I messing up
somewhere in the concepts?

Thanks,
-Kartik

 
 
 
Top

Signal handlers are not reset after signal delivery

Post by Rob Rya » Tue, 18 Aug 1998 04:00:00



> The man page for signal says

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

> However I tried the following simple program and found that if I install
> a signal handler once, it remains installed over multiple deliveries of
> the same signal. i.e. the signal does not get  reset to its default
> behaviour when raised.

You are probably using a system with glibc (libc6).  The developers of
glibc chose to make signal default to the more useful BSD semantics
where the signal handler is not uninstalled after being received.
(Personally I think this decision was misguided, as it represents yet
another incompatibility with the common commercial Unixen.)

-Rob

 
 
 
Top

Signal handlers are not reset after signal delivery

Post by Paul Mart » Tue, 18 Aug 1998 04:00:00



>You are probably using a system with glibc (libc6).  The developers of
>glibc chose to make signal default to the more useful BSD semantics
>where the signal handler is not uninstalled after being received.
>(Personally I think this decision was misguided, as it represents yet
>another incompatibility with the common commercial Unixen.)

You can have both (from man signal):

       Since  libc6,  signal  uses  BSD semantics and the default
       behaviour is not reset when the signal is raised. You  may
       use sysv_signal to get SysV semantics.

       Both  signal and sysv_signal are library routines built on
       top of sigaction(2).

--

at home, swap dash to dot to email.

 
 
 
Top

Signal handlers are not reset after signal delivery

Post by H. Peter Anv » Wed, 19 Aug 1998 04:00:00




In newsgroup: comp.os.linux.development.system


> >You are probably using a system with glibc (libc6).  The developers of
> >glibc chose to make signal default to the more useful BSD semantics
> >where the signal handler is not uninstalled after being received.
> >(Personally I think this decision was misguided, as it represents yet
> >another incompatibility with the common commercial Unixen.)

> You can have both (from man signal):

>        Since  libc6,  signal  uses  BSD semantics and the default
>        behaviour is not reset when the signal is raised. You  may
>        use sysv_signal to get SysV semantics.

>        Both  signal and sysv_signal are library routines built on
>        top of sigaction(2).

It is pretty much a gratuitous change, though.  Either way, the
solution is quite simple... "don't use signal(2/3)."  sigaction(2) is
the way to go on any platform.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 
Top

1. Signal handlers inside signal handlers

Greetings Netters,

Unfortunately, the project I'm working on requires I mess with nested signal
handlers, and I've checked out obvious manuals and the POSIX std for clues,
but I'm having no luck.

What I'm trying to do is within a signal handler, plant another handler.
For example

#include        blah blah blah

foo2( int signo )
{
        printf("Caught the second sigalrm\n");

foo1( int signo )
{
        printf("Caught the first sigalrm\n");
        signal( SIGARLM, foo2 );
        alarm(1);

        for (;;)
                ;

main()
{
        signal( SIGALRM, foo1 );
        alarm(3);

        /* Wait for the first alarm */
        sleep(10);

The above program when run, prints the message from function foo1
but never reaches foo2.  Note that my project dictates that I can't
exit foo2, until foo1 has run.
I've tried messing with posix signals (sigaction etc), but have the
same problem.

Has anyone tried to do this sort of thing before??

Thanks in advance,
Scott Wallace

2. roadrunner

3. blocked signal delivery and signal sets

4. syslog: accept: SIOCGPGRP failed errno 2

5. Threads performance - allow signal handler to not call handler

6. ATAPI CD Roms and Solaris 2.5 x86

7. blocking signals in signal handler -- True or False quiz

8. Does anyone know of a free c++ compiler

9. Registering signal inside signal handler

10. Registering client data on signal manager side andreceiving it in signal handler

11. --- called from signal handler with signal -24242176 (SIG Unknown)

12. signal mask and signal handler

13. Setting a Signal handler to signal the input on a socket


All times are UTC
Board index