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.
