Re: unsafe functions from signal handler


Nils O. Selåsdal wrote:
bill pursell wrote:
I came upon the following code yesterday in a signal handler:

fflush(stderr);
fprintf(stderr, "...%d\n", signal);
fflush(stderr);
/* snip */
exit(-1);

This brought to mind several questions:

1. fprintf is not a safe function, so it is a bad idea to
call it from within a signal handler. However, it strikes
me that the only problem with it is that the writes to stderr
will be interleaved and munged a bit. Is there a more
substantial problem? Also, does it matter if the signal
If the main program is in the middle of updating the fields
in the FILE, and a signal occurse, reading/writing half garbled
members havoc might follow (there are various X_unlocked functions)

FILE operations are normally locked though on posixishy systems with
pthreads (yes - even if your program doesn't use threads - just as with
malloc :-) so you risk deadlocking your program.

Is the deadlock condition still possible if the sigaction resets
the signal dispostion to abort? (so the first signal enters the
handler which calls printf, but the second signal causes an abort)

.