Re: [Bug-gnulib] addition: fatal-signal.h, fatal-signal.c

[Paul Eggert]

Bruno Haible <address@hidden> writes:
Bruno Haible <address@hidden> writes:

> In gettext I need fatal-signal for two purposes:
>   - Reaping subprocesses. Here I call atexit() and at_fatal_signal()
>     with the same cleanup function.
>   - Removing temporary files. Here I don't call atexit() because if
>     the program exits (due to a fatal error from the subprocess) the
>     user needs to be able to look at the temporary file.

I don't follow the latter point: did you mean "I don't call
at_fatal_signal()" perhaps?  If so, then it's typical for programs to
want to clean up temporary files even with fatal signals; if not, then
I'm lost.

It sounds like you want to remove temporary files in some cases, but
not others.  One way to do that is to register the cleanup function
only in the cases where you want to remove temporary files.  Another
way is to have the cleanup function inspect variables that tell it
what needs cleaning up.  The latter method scales better to programs
that have complicated cleanup policies, and it's more important for
the API to cater to the latter method than to the former.  But quite
possibly I'm not understanding your situation.

> > You might want to add SIGRTMIN through SIGRTMAX to that list.
> 
> No, these signals are marked as "reserved for application use" by POSIX.
> And in some ports of LinuxThreads, SIGRTMIN and SIGRTMIN + 1 are used
> for communication with the process' thread manager. I won't touch these
> signals in a general facility.

I agree.  I meant only that SIGRTMIN..SIGRTMAX should be added to the
list of signals in the comment, i.e. signals that cause the program to
exit but which the code doesn't catch for one reason or another.

> All reasonable applications that use mmap() this way should
> have their own SIGBUS/SIGSEGV handler installed. And then the signal
> is not fatal any more and shouldn't be treated by at_fatal_signal().

For many programs, these errors are handled in a way that's almost
entirely equivalent to fatal signals.  Typically the only thing that
the program can do with such errors to clean up and exit (without a
core dump of course).  It should be convenient and natural for
programs to do this, and it'd be nice if fatal-signal supported this
in an integrated way.

> Do you really want a cleanup function that does a different thing
> for SIGHUP than for SIGTERM?

Sure.  I might want the cleanup function to print the name of the
signal that killed it.  I might want even more details: if the
implementation supports POSIX 1003.1-2001, I might want to use the
siginfo_t information to print extra information associated with the
signal, or to do some conditional cleanup based on the information
associated with the signal.