[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/2.6.29.2; 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,
> SIGPIPE, SIGCHLD etc.).
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.
-mike
signature.asc
Description: This is a digitally signed message part.