X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Tue, 23 Dec 2003 21:56:38 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Gisle Vanem" <giva AT bgnett DOT no>
Message-Id: <9003-Tue23Dec2003215638+0200-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <22ca01c3c974$aa833260$0600000a@broadpark.no> (giva@bgnett.no)
Subject: Re: pending SIGALRM
References: <207a01c3c8c6$26445c80$0600000a AT broadpark DOT no> <uisk7irn3 DOT fsf AT elta DOT co DOT il> <22ca01c3c974$aa833260$0600000a AT broadpark DOT no>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Gisle Vanem" <giva AT bgnett DOT no>
> Date: Tue, 23 Dec 2003 17:49:00 +0100
> 
> I'm not sure I should use SIG_SETMASK on all signals or
> only on SIGALRM. Or use the same masking technique for all 
> signals. Is there a benefit doing that instead of catching
> and reraising the signals (besides portability) ?

I think it's better to block all signals with `sigprocmask'.  Catching
signals is a tricky business, especially on Windows, but not only
there.  For starters, you need to save and restore previous handlers.
And then there are complications with 3-4 different methods used on
different systems to install signal handlers; even DJGPP supports both
`signal' and `sigaction'.  Jumping out of a signal handler is
non-trivial, too: most systems will need sigsetjmp/siglongjmp to do
that properly, and the fine print in the docs will tell you that some
variables may not be preserved across sigsetjmp/siglongjmp unless you
take special precautions, like declare them `volatile'.

It is better to avoid all this mess, if you can.  `sigprocmask' allows
you to leave all this stuff to the library implementors and not touch
any signal handlers at all.  In addition, using it will allow for more
elegant and simple code, and avoid the need to answer questions why
some signals are blocked while others are caught.

Anyway, I'm not sure I understand what is your question, beyond the
ones you asked in the original message.  Is the code you've shown
failing in some way?  If so, what isn't working there, and how it
fails, exactly?

Btw, one comment about your code:

> void sock_sig_restore (int sig)
> {
>   sigset_t pending;
>   if (sigpending(&pending) == 0 &&
>       sigismember(&pending,SIGALRM) == 1) &&
>       sigprocmask(SIG_UNBLOCK, &new_mask, &old_mask))
>     ;  /* calls the alarm() handler now when it's safe */

There's no need to call the alarm() handler after unmasking SIGALRM,
since if that signal is pending, it will be delivered before
`sigprocmask' returns (this is documented in the libc manual).  In
other words, `sigprocmask' raises all the unblocked pending signals
for you, as part of its execution (see the sources).