Very Computer

I've been working on a project where two processes send each other the
SIGUSR1 signal to indicate certain events have taken place.  It seems like
every time I catch a signal (using:  signal(SIGUSR1, whatever);), that the
next signal (of SIGUSR1) would kill the process.

I eventually decided that it must be the case that when the signal is caught,
the action automatically reverts to the default.  I kludged this by reregister-
ing the signal in the handler itself and it seems to work fine (for the most
part <sigh>).

Has anybody else encountered this problem/situation?  Please respond via
email if possible, and I will post the results back to the group if any.

                                - Brian

P.S.:  I _do_ check the return code of signal, and it does _not_ return an
       error...

Use sigaction(), it is POSIX and allows you to select whether you want
this behaviour or not.

Witty .sig under construction.

Sure. This is a nature of the (non BSD) signal(2) calls.
I would suggest using sigaction(2) (POSIX compliant) mechanizm instead.

Quote:

>I eventually decided that it must be the case that when the signal is caught,
>the action automatically reverts to the default.  I kludged this by reregister-
>ing the signal in the handler itself and it seems to work fine (for the most
>part <sigh>).

This is not a kludge - it is "the way" the non-BSD signals should be programmed.
But when the signals come one after another, it fails.

Quote:> [...]
>P.S.:  I _do_ check the return code of signal, and it does _not_ return an
>       error...

Of course it does not return any error. Why should it ?

        Zenon

tha's not weird, that's the normal behavior in ALL implementations (as far I know:)

--
                                        Steffen Ullrich

                    http://www.xensei.com/users/ccrlphr/

sigaction() is POSIX, but using it to select BSD semantics is not.
The portable way to handle this is what the original poster was doing:

    void
    catcher(int sig)
    {
        signal(sig, catcher);
        /* other code */
    }
    ...
        signal(SIGFOO, catcher);
--
Shields.

Oops.  My fault for not reading the book carefully enough.  Though,
SA_RESTART is defined in both 4.3+BSD and SVR4, so I wouldn't say it is
too non-portable...

Quote:>The portable way to handle this is what the original poster was doing:

>    void
>    catcher(int sig)
>    {
>    signal(sig, catcher);
>    /* other code */
>    }
>    ...
>        signal(SIGFOO, catcher);

I have been wondering if this would leave a window where the signal is not
catched.  Is the signal unmasked when the handler is entered?

Witty .sig under construction.

Not BSD.
--
Shields.