Editing Signal (IPC) (section)

==Handling signals==
Signal handlers can be installed with the [[sigaction|{{tt|signal(2)}} or {{tt|sigaction(2)}}]] system call. If a signal handler is not installed for a particular signal, the default handler is used.  Otherwise the signal is intercepted and the signal handler is invoked. The process can also specify two default behaviors, without creating a handler: ignore the signal (SIG_IGN) and use the default signal handler (SIG_DFL). There are two signals which cannot be intercepted and handled: [[#SIGKILL|SIGKILL]] and [[SIGSTOP]].

===Risks===
Signal handling is vulnerable to [[race condition]]s. As signals are asynchronous, another signal (even of the same type) can be delivered to the process during execution of the signal handling routine.

The {{tt|sigprocmask(2)}} call can be used to block and unblock delivery of signals. Blocked signals are not delivered to the process until unblocked. Signals that cannot be ignored (SIGKILL and SIGSTOP) cannot be blocked.

Signals can cause the interruption of a system call in progress, leaving it to the application to manage a [[PCLSRing|non-transparent restart]].

Signal handlers should be written in a way that does not result in any unwanted side-effects, e.g. {{tt|[[errno.h|errno]]}} alteration, signal mask alteration, signal disposition change, and other global [[Process (computing)|process]] attribute changes. Use of non-[[Reentrancy (computing)|reentrant]] functions, e.g., {{tt|[[malloc]]}} or {{tt|[[printf]]}}, inside signal handlers is also unsafe. In particular, the POSIX specification and the Linux man page {{Tt|signal (7)}} require that all system functions directly or ''indirectly'' called from a signal function are ''async-signal safe''.<ref>{{Cite web|title=The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition: System Interfaces Chapter 2|url=https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04|access-date=2020-12-20|website=pubs.opengroup.org}}</ref><ref>{{Cite web|title=signal(7) - Linux manual page|url=https://man7.org/linux/man-pages/man7/signal.7.html|access-date=2020-12-20|website=man7.org}}</ref> The {{tt|signal-safety(7)}} man page gives a list of such async-signal safe system functions (practically the [[system call]]s), otherwise it is an [[undefined behavior]].<ref>{{Cite web|title=signal-safety(7) - Linux manual page|url=https://man7.org/linux/man-pages/man7/signal-safety.7.html|access-date=2020-12-20|website=man7.org}}</ref> It is suggested to simply set some {{code|volatile sig_atomic_t}} variable in a signal handler, and to test it elsewhere.<ref>{{Cite web|title=The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition: <signal.h>|url=https://pubs.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html|access-date=2020-12-20|website=pubs.opengroup.org}}</ref>

Signal handlers can instead put the signal into a [[Queue (abstract data type)|queue]] and immediately return. The main thread will then continue "uninterrupted" until signals are taken from the queue, such as in an [[event loop]]. "Uninterrupted" here means that operations that [[Blocking (computing)|block]] may return prematurely and [[PCLSRing|must be resumed]], as mentioned above. Signals should be processed from the queue on the main thread and not by [[Thread pool|worker pools]], as that reintroduces the problem of asynchronicity. However, managing a queue is not possible in an async-signal safe way with only {{tt|sig_atomic_t}}, as only single reads and writes to such variables are guaranteed to be atomic, not increments or (fetch-and)-decrements, as would be required for a queue. Thus, effectively, only one signal per handler can be queued safely with {{tt|sig_atomic_t}} until it has been processed.