With one exception, accessing Accessing or modifying shared objects in signal handlers can lead to race conditions, opening up security holes. The exception to this rule is the ability to read and write to variables of volatile sig_atomic_t. The type of sig_atomic_t is implementation-defined, although there are bounding constraints. Only integer values from 0 through 127 can be assigned to a variable of type sig_atomic_t to be fully portable.
According to the "Signals and Interrupts" section of the C99 Rationale, other than calling a limited, prescribed set of library functions:
The C89 Committee concluded that about the only thing a strictly conforming program can do in a signal handler is to assign a value to a
volatile staticvariable which can be written uninterruptedly and promptly return.
The C99 standard dictates the use of volatile sig_atomic_t. The type of sig_atomic_t is implementation-defined, although there are bounding constraints. Only assign integer values from 0 through 127 to a variable of type sig_atomic_t to be fully portableHowever, this issue was discussed at the April 2008 meeting of ISO/IEC WG14 and it was agreed that there are no known implementations in which it would be an error to read a value to from a volatile static variable and that this was the original intent of the committee and was not properly recorded.
The signal handler may also call the abort() function, the _Exit(), function, or the signal() function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. This may be necessary to ensure that the handler persists (see SIG01-A. Understand implementation-specific details regarding signal handler persistence).
...