X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Date: 23 Dec 2003 15:35:12 +0200 Message-Id: From: Eli Zaretskii To: "Gisle Vanem" 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 Precedence: bulk > From: "Gisle Vanem" > 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.