X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
Date:	23 Dec 2003 15:35:12 +0200
Message-Id:	<uisk7irn3.fsf@elta.co.il>
From:	Eli Zaretskii <eliz AT elta DOT co DOT il>
To:	"Gisle Vanem" <giva AT bgnett DOT no>
CC:	djgpp AT delorie DOT com
In-reply-to:	<207a01c3c8c6$26445c80$0600000a@broadpark.no> (giva@bgnett.no)
Subject:	Re: pending SIGALRM
References:	<207a01c3c8c6$26445c80$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

> From: "Gisle Vanem" <giva AT bgnett DOT no>
> Date: Mon, 22 Dec 2003 20:59:46 +0100
> 
> The documentation says an "alarm(0)" should cancel a
> pending SIGALRM

No, it says that "alarm(0)" ``cancels any pending alarm''.  Note that
it doesn't say SIGALRM, just ``alarm''.  This means that a signal that
was already raised won't be affected.  ``Pending alarm'' here means
that the program called "alarm(x)" previously and that alarm's time
has not yet come; in such a case, a new call will prevent the
previously set alarm from firing and will replace it with the new
alarm.

The Posix spec says it even better:

   If seconds is 0, a pending alarm request, if any, is canceled.
                    ^^^^^^^^^^^^^^^^^^^^^^^
So it's the _request_ that's canceled, not the signal itself.

> __sigprocmask_pending_signals isn't cleared AFAICS. 

Clearing __sigprocmask_pending_signals was not implemented, as I'm
not sure we should do that.  Do other systems (e.g., GNU/Linux) clear
the pending SIGALRM when `alarm(0)' is called?  If they do, we
probably should do that as well.

FWIW, the Posix spec says:

   If the SIGALRM signal has not yet been generated, the call shall
   result in rescheduling the time at which the SIGALRM signal is
   generated.

As you see, it keeps silent about the case where the signal was
already generated, but not yet delivered.

> And how should "alarm(x)" behave while a SIGALRM was 
> blocked and the first SIGALRM didn't fire? Should the original
> signal be raised and new signal again in x seconds?

The spec for blocked signals doesn't say, AFAICT, what should happen
in such cases.  The DJGPP libc Info manual says (under `sigprocmask'):

   The DJGPP implementation only records a single occurrence of any given
   signal, so when the signal is unblocked, its handler will be called at
   most once.

> The doc's (alarm.txh) says "the new alarm delay will supercede 
> the prior call."

Again, this only tells what happens with an alarm request that did
not fire yet.

- Raw text -