Linux – Handling Signals in a Multithreaded Application

Signals are very useful feature in linux to send notification from one process to another and from the kernel to the process. Signals are sent in some error cases (accessing wrong memory address, bus error, floating point error, …) and also to inform the user application (timer expired, child process finished, IO is ready, ….)

The signal context

While a signal arrives on a single threaded process, the thread complete the current instruction, jump to the signal handler and return when it finish.

Signal handlers are per process, signal masks are per thread

On a multithreaded application – the signal handler execute in one of the thread contexts. We can’t predict the thread that will be chosen to run the signal handler:

consider the following example:

Compile and run the app, you will see periodic output for each thread:

Now send a signal to the process using the kill command:

The kernel choose one thread and run the signal handler in its context. In my case thread 1 selected so the output for 10 times is:

This behaviour can be problematic in case the selected thread is an important task

(Note that if the signal is an exception (SIGSEGV, SIGFPE, SIGBUS, SIGILL, …) the signal will be caught by the thread doing the exception)

We can’t choose the selected thread but we can do a little trick to hack the system to choose the thread we want. The trick is to block the signal on all threads except one thread – the one we want ┬áto run the signal in:

We block the signal on threads 1,2 so the system will deliver the signal to thread 3

Run the app, send the signal with kill command. The output:

Another trick is to create a thread for signal handling that will be blocked using sigwait , waiting for signal

Behind the scenes

Inside the kernel, each thread has a task_struct object defines in sched.h:

All the signals fields are stored per thread. Actually , there is no structure for the process , all the threads on the same process points to the same memory and files tables so the kernel need to choose a thread to deliver the signal to:


Sending signals to a thread

Another option is to use pthread_kill(3) to send a signal directly to a thread. This can be done only in the same process. For example:

We start with creating 3 threads, then we send a signal to thread 1, wait for the signal handler to finish then send signals both to threads 2 and 3 , they will run the signal handler at the same time so in this case we will see :




4 thoughts on “Linux – Handling Signals in a Multithreaded Application

  1. nice post…

  2. hi there !,

    just came across this post, and have a trivial comment: instead of each thread explicitly masking out signals you can just mask the signals out in the main thread (before other threads are created) threads created subsequently, will inherit the copy of main thread’s signal mask. a dedicated signal-handling thread can express interest in signals that it wishes to handle via sigwaitinfo(…) and friends…

    kind regards

    1. Good note. Thanks

  3. A small note on the handler. You have to be careful what functions you call, puts(3) is not signal handler safe.

Leave a Reply

Your email address will not be published.