Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c

[Bruno Haible]

Hi Eric,

> When used in a library, the gnulib fatal-signal module must assume that
> the rest of the program can use SIGPOLL and SIGALRM for its own purposes.
> But when used in a stand-alone app, such as csplit, where it is known in
> advance that these signals are not used, it would be nice to include them
> in the set of fatal signals.

Note that this makes the program harder to maintain. You add a call to sleep()
for debugging, and you suddenly see strange things... (There may be interactions
between sleep() and SIGALRM, see
<http://www.gnu.org/software/libtool/manual/libc/Sleeping.html>.)

Personally, I wouldn't change programs to react on SIGPOLL or SIGALRM that
are sent from outside the process. SIGPOLL and SIGALRM are not meant to be
used this way. The user who wants to kill a running process has enough
choice among SIGINT, SIGHUP, SIGTERM, SIGQUIT. Your proposed change would
negatively affect the _proper_ uses of SIGPOLL and SIGALRM in order to
improve the _improper_ uses of these signals.

> In other words, right now, csplit is _not_
> using fatal-signals, because it wants to react to additional signals
> beyond the default provided by the gnulib module.  Is there a way we could
> extend the API of fatal-signals to allow an application to request that
> SIGPOLL and SIGALRM be added to the set of signals to react to?

Yes, feel free to add such API to the 'fatal-signal' module. I propose a
function

  extern void init_fatal_signals (sigset_t signals_to_include,
                                  sigset_t signals_to_exclude);

that would change the set of "fatal" signals to

  (fatal_signals | signals_to_include) & ~signals_to_exclude

Bruno