[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked

From: Bruno Haible
Subject: Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked
Date: Tue, 19 May 2009 12:22:05 +0200
User-agent: KMail/1.9.9

Mike Frysinger wrote:
> Some systems might have SIGALRM blocked when running configure.  If that
> is the case, the nanosleep() test will sleep for practically ever as the
> signal generated by alarm() is never delivered.  As such, we should make
> sure to unblock SIGALRM before running any tests.

POSIX:2001 and POSIX:2008 say [in the description of exec()]:
       "it should be noted that many existing applications wrongly
        assume that they start with certain signals set to the default
        action and/or unblocked. In particular, applications written
        with a simpler signal model that does not include blocking of
        signals, such as the one in the ISO C standard, may not behave
        properly if invoked with some signals blocked. Therefore, it is
        best not to block or ignore signals across execs without explicit
        reason to do so, and especially not to block signals across execs
        of arbitrary (not closely co-operating) programs."

Therefore, IMO, it's better (less work) to fix the few programs which
erroneously block signals before calling exec(), rather than add additional
code to *all* programs which use signals in one way or the other (SIGALRM,

> This crops up from time to time on Linux systems (google for "SIGALRM
> blocked" for examples).

I googled as you say and found these pages that indicate a bug in very
few, very specific programs:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]