Signal handling with multiple threads in Linux
In Linux, what happens when a program (that possibly has multiple threads) receives a signal, like SIGTERM or SIGHUP? Which thread intercepts the signal? Can multiple threads get the same signal? Is there a special thread dedicated entirely to handling signals? If not, what happens inside the thread that is to handle the signal? How does the execution resume after the signal handler routine finishes?
2 Answers 2
pthreads(7) describes that POSIX.1 requires all threads in a process share attributes, including:
POSIX.1 also requires some attributes to be distinct for each thread, including:
The Linux kernel’s complete_signal routine has the following code block — the comments are quite useful:
/* * Now find a thread we can wake up to take the signal off the queue. * * If the main thread wants the signal, it gets first crack. * Probably the least surprising to the average bear. */ if (wants_signal(sig, p)) t = p; else if (!group || thread_group_empty(p)) /* * There is just one thread and it does not need to be woken. * It will dequeue unblocked signals before it runs again. */ return; else < /* * Otherwise try to find a suitable thread. */ t = signal->curr_target; while (!wants_signal(sig, t)) < t = next_thread(t); if (t == signal->curr_target) /* * No thread needs to be woken. * Any eligible threads will see * the signal in the queue soon. */ return; > signal->curr_target = t; > /* * Found a killable thread. If the signal will be fatal, * then start taking the whole group down immediately. */ if (sig_fatal(p, sig) && !(signal->flags & SIGNAL_GROUP_EXIT) && !sigismember(&t->real_blocked, sig) && (sig == SIGKILL || !p->ptrace)) < /* * This signal will be fatal to the whole group. */ So, you see that you are in charge of where signals are delivered:
If your process has set a signal's disposition to SIG_IGN or SIG_DFL , then the signal is ignored (or default -- kill, core, or ignore) for all threads.
If your process has set a signal's disposition to a specific handler routine, then you can control which thread will receive the signals by manipulating specific thread signal masks using pthread_sigmask(3) . You can nominate one thread to manage them all, or create one thread per signal, or any mixture of these options for specific signals, or you rely on the Linux kernel's current default behavior of delivering the signal to the main thread.
Some signals, however, are special according to the signal(7) man page:
A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2)) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3)). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.
What happens to a multithreaded Linux process if it gets a signal?
If a Unix (Posix) process receives a signal, a signal handler will run. What will happen to it in a multithreaded process? Which thread receives the signal? In my opinion, the signal API should be extended to handle that (i.e. the thread of the signal handler should be able to be determined), but hunting for infos on the net I only found year long flames on the linux kernel mailing list and on different forums. As I understood, Linus' concept differed from the Posix standard, and first some compat layer was built, but now the Linux follows the posix model. What is the current state?
Duplicate of stackoverflow.com/questions/11679568/… "pthreads(7) describes that POSIX.1 requires all threads in a process share attributes, including signal dispositions"
@steve Thanks, but 1) it is on another SE site 2) this spec doesn't specify clearly, what will exactly happen. What it means, the signal handlers will be called on all threads, but it seems a little bit surrealistic to me. 3) That answer doesn't specify what was Linus' model and why/how is it used currently.
2 Answers 2
The entry in POSIX on "Signal Generation and Delivery" in "Rationale: System Interfaces General Information" says
Signals generated for a process are delivered to only one thread. Thus, if more than one thread is eligible to receive a signal, one has to be chosen. The choice of threads is left entirely up to the implementation both to allow the widest possible range of conforming implementations and to give implementations the freedom to deliver the signal to the "easiest possible" thread should there be differences in ease of delivery between different threads.
From the signal(7) manual on a Linux system:
A signal may be generated (and thus pending) for a process as a whole (e.g., when sent using kill(2) ) or for a specific thread (e.g., certain signals, such as SIGSEGV and SIGFPE, generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using pthread_kill(3) ). A process-directed signal may be delivered to any one of the threads that does not currently have the signal blocked. If more than one of the threads has the signal unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.
Threads have distinct alternate signal stack settings. However, a new thread's alternate signal stack settings are copied from the thread that created it, so that the threads initially share an alternate signal stack (fixed in kernel 2.6.16).
From the pthreads(3) manual on an OpenBSD system (as an example of an alternate approach):
Signals handlers are normally run on the stack of the currently executing thread.
(I'm currently not aware of how this is handled when multiple threads are executing concurrently on a multi-processor machine)
The older LinuxThread implementation of POSIX threads only allowed distinct single threads to be targeted by signals. From pthreads(7) on a Linux system:
LinuxThreads does not support the notion of process-directed signals: signals may be sent only to specific threads.