1.<\/p>\n<\/td>\n
Ensure that (a) the signal handler calls only async-signal-safe functions, and (b) the signal handler itself is reentrant with respect to global variables in the main program.<\/p>\n<\/td>\n<\/tr>\n
2.<\/p>\n<\/td>\n
Block signal delivery in the main program when calling functions that are unsafe or operating on global data that is also accessed by the signal handler.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n
Generally, the second choice is difficult in programs of any complexity, so the first choice is taken.<\/p>\n
POSIX.1 specifies a set of functions that an implementation must make async-signal-safe. (An implementation may provide safe implementations of additional functions, but this is not required by the standard and other implementations may not provide the same guarantees.)<\/p>\n
In general, a function is async-signal-safe either because it is reentrant or because it is atomic with respect to signals (i.e., its execution can\u2019t be interrupted by a signal handler).<\/p>\n
The set of functions required to be async-signal-safe by POSIX.1 is shown in the following table. The functions not otherwise noted were required to be async-signal-safe in POSIX.1-2001; the table details changes in the subsequent standards.<\/p>\n
![\"Image](\"grohtml-962901.png\")
<\/p>\n
Notes:<\/p>\n
| <\/td>\n | \n *<\/p>\n<\/td>\n | <\/td>\n | \n POSIX.1-2001 and POSIX.1-2001 TC2 required the functions fpathconf<\/b>(3), pathconf<\/b>(3), and sysconf<\/b>(3) to be async-signal-safe, but this requirement was removed in POSIX.1-2008.<\/p>\n<\/td>\n<\/tr>\n *<\/p>\n<\/td>\n If a signal handler interrupts the execution of an unsafe function, and the handler terminates via a call to longjmp<\/b>(3) or siglongjmp<\/b>(3) and the program subsequently calls an unsafe function, then the behavior of the program is undefined.<\/p>\n<\/td>\n<\/tr>\n *<\/p>\n<\/td>\n POSIX.1-2001 TC1 clarified that if an application calls fork<\/b>(2) from a signal handler and any of the fork handlers registered by pthread_atfork<\/b>(3) calls a function that is not async-signal-safe, the behavior is undefined. A future revision of the standard is likely to remove fork<\/b>(2) from the list of async-signal-safe functions.<\/p>\n<\/td>\n<\/tr>\n *<\/p>\n<\/td>\n Asynchronous signal handlers that call functions which are cancellation points and nest over regions of deferred cancellation may trigger cancellation whose behavior is as if asynchronous cancellation had occurred and may cause application state to become inconsistent.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n errno<\/b> Deviations in the GNU C library<\/b> *<\/p>\n<\/td>\n Before glibc 2.24, execl<\/b>(3) and execle<\/b>(3) employed realloc<\/b>(3) internally and were consequently not async-signal-safe. This was fixed in glibc 2.24.<\/p>\n<\/td>\n<\/tr>\n *<\/p>\n<\/td>\n The glibc implementation of aio_suspend<\/b>(3) is not async-signal-safe because it uses pthread_mutex_lock<\/b>(3) internally.<\/p>\n<\/td>\n<\/tr>\n<\/table>\n |