[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: Mike Frysinger
Subject: Re: [PATCH] mktime & nanosleep: make sure SIGALRM is not blocked
Date: Tue, 19 May 2009 06:49:56 -0400
User-agent: KMail/1.11.3 (Linux/; KDE/4.2.3; x86_64; ; )

On Tuesday 19 May 2009 06:22:05 Bruno Haible wrote:
> 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,

i'm not talking about all programs.  i'm talking about the common ones i keep 
fielding bug reports for (gnulib).  in the process, we're of course trying to 
figure out who is blocking the signal in the first place, but it isnt exactly 
a trivial affair when it crops up on some users systems and they cant always 
reproduce it.

> > 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:
>   <http://www.vttoth.com/sigalrm.htm>
>   <http://lkml.indiana.edu/hypermail/linux/kernel/0510.0/0727.html>

which are unrelated to the reports i'm dealing with currently afaik.

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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