In which situations a signal handler can be executed in the non-main thread?

Question

My question is just what the title says (for Unix/Linux only). I assume that user calls to std::raise and std::abort are always executed in the same thread that made the call, but, I have some questions about asynchronous and kernel routines sending signals...

• If I send a signal from command line to a thread pid, will the thread treat the signal or it will be treated by the main thread depending on which signal has been sent?
• If malloc detects some heap corruption, will the signal be sent to the main thread or will be executed as well in the thread that called malloc? The same questions applies to bugs generating SIGFPEs or SIGSEGVs.
• There are signal that are always treated by the main thread regardless which thread causes it, or to which pid was sent to?
• Which other situations are worth mention in multithread contexts?

Answer 1

The main() thread is not special. It receives signals like any other thread.

When a signal is generated "asynchronously" for a process or process group (e.g., by kill or a Ctrl-C at the terminal), the implementation may choose any thread for delivery.

The thread executing main() is no different from any other thread in the process. If you want to control which thread receives the signal, you must block signal delivery in all but one thread, or block and call sigwait from your desired thread.

When a signal is generated "synchronously" within a thread (as by raise, abort, a segmentation fault, etc.) or is targeted at a specific thread (as by pthread_kill), then that thread, and only that thread, will get the signal. If that thread is blocking the signal, then the signal is held pending until unblocked or accepted.

Two very good sources here are the comprehensive but comparatively dense POSIX treatment and the pleasantly accessible GNU libc treatment of UNIX signals. Both are oriented for C rather than C++, however.