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.).
> 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>
Bruno
