Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | John Levon wrote:
>>>> Or should the code in child_handler be truly trivial:
>>> Yes.
>>
> | John, I take it that you're (almost) happy with the existing
> | signal handling code in error_handler below. To my mind it needs
> | only a handling_error flag to ensure that it handles multiple
> | signals safely. (The SIGPIPE should be removed if it isn't an
> | error.)
>>
> | Thoughts?
> | Angus
>>
> | static void error_handler(int err_sig)
> | {
> | + static sig_atomic_t handling_error = false;
> | + if (handling_error)
> | + return;
> | + handling_error = true;
>
> Hmm... why do you think this is needed?
>From Advanced Linux Programming (url in previous mail in this thread),
chapter 3, page 53:
Because signals are asynchronous, the main program may be in a very
fragile state when a signal is processed and thus while a signal
handler function executes. Therefore, you should avoid performing any
I/O operations or calling most library and system functions from
signal handlers.
A signal handler should perform the minimum work necessary to respond
to the signal, and then return control to the main program (or
terminate the program). In most cases, this consists simply of
recording the fact that a signal occurred.The main program then
checks periodically whether a signal has occurred and reacts
accordingly.
It is possible for a signal handler to be interrupted by the delivery
of another signal. While this may sound like a rare occurrence, if it
does occur, it will be very difficult to diagnose and debug the
problem. (This is an example of a race condition, discussed in
Chapter 4, Threads, Section 4.4, Synchronization and Critical
Sections. ) Therefore, you should be very careful about what your
program does in a signal handler.
--
Angus
