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.
How Linux handles threads and process scheduling
I'm trying to understand how Linux handles process scheduling and thread scheduling. I read that Linux can schedule both processes and threads. Does Linux have a thread scheduler AND a process scheduler? If yes, how do they cooperate?
I'm speaking in general , about kernel threads not user threads. I don't know what's a thread library .
3 Answers 3
The Linux kernel scheduler is actually scheduling tasks, and these are either threads or (single-threaded) processes.
So a task (a task_struct inside the kernel), in the context of the scheduler, is the thing being scheduled, and can be some kernel thread like kworker or kswapd , some user thread of a multi-threaded process (like firefox ), or the single-thread of a single-threaded process (like bash ), identified with that single-threaded process.
A process is a non-empty finite set (sometimes a singleton) of threads sharing the same virtual address space (and other things like file descriptors, working directory, etc etc. ). See also credentials(7), capabilities(7) etc.
Threads on Linux are kernel threads (in the sense of being managed by the kernel, which also creates its own threads), created by the Linux specific clone syscall (which can also be used to create processes on Linux). The pthread_create function is probably built (on Linux) above clone inside NPTL and Gnu Libc (which integrated NPTL on Linux) and musl-libc.