malloc's and signals -- a dangerous mixture?

[Doug Gwyn]

In article <1064 at dinl.mmc.UUCP> noren at dinl.UUCP (Chuck Noren) writes:
>...  Could someone shed some light on the subject and possibly provide
>some rules when malloc's are safe (and portable) to use with signals. 

In general, for portable applications, signal handlers are unsafe for
almost ANY use.  If you know for sure that a signal either will not
recur while processing an instance of it or will not have the handler
reset to SIG_DFL during handling, then it is safe to set an shared
atomic flag from within the signal handler and resume where interrupted.
The proposed C standard specifies a small number of other things that
are supposed to be safe for signal handlers to do (assuming a standard-
conforming implementation), but I don't know how to implement some of
them reliably in typical UNIX environments (for example).  I argued in
X3J11 meetings against guaranteeing anything at all for signal handlers.

POSIX (or similar) "reliable signals" permit more things to be done
safely within signal handlers; however, it is still not safe in general
to invoke the majority of C library routines from a signal handler.
The cost of making them safely reentrant will probably preclude most
implementors from doing so.  Vendors of so-called "real time" systems
may decide to do so, but I wouldn't expect others to.

The "signal" mechanism was not really intended to support concurrent
programming; it was meant to provide a way to handle abnormal conditions
short of simply aborting the process.  Trying to do other things with
it will eventually get you in trouble.