2

I'm writing a multi-threaded program in C, where the main() changes the behavior of some signals and then spawns more threads. The question is: do the other threads continue executing when a signal arrives, or do they pause and resume execution when the signal is handled?

Thanks

27C256
  • 23
  • 4
  • 4
    Possible duplicate of [Wait for signal, then continue execution](https://stackoverflow.com/questions/47658347/wait-for-signal-then-continue-execution) – Nawrez Dec 28 '17 at 11:03
  • No, other threads are not paused. But even if they would be paused, I think this wouldn't help you. –  Dec 28 '17 at 11:04
  • The interaction between threads and signals is undefined by the C standard, so there is no general answer to that. Please tag your question with your operating system and/or thread standard that you are using. – Jens Gustedt Dec 28 '17 at 11:44
  • 1
    I'm working with POSIX threads and on Linux 4.4. Also I'm not asking how I can pause the execution of the threads, I'm asking if the other threads are paused when a signal arrives or not, because depending on the answer I'll have to continue programming doing one thing or another. Thanks. – 27C256 Dec 28 '17 at 11:58
  • If the threads are all running on the same CPU, then they stop while the signal handler is running. If they are all running on different CPUs, then only the thread receiving the signal runs the signal handler. – stark Dec 28 '17 at 18:55
  • As a rule of thumb, multi-threading is not friendly to signals. Consider using [signalfd(2)](https://man7.org/linux/man-pages/man2/signalfd.2.html) with [poll(2)](https://man7.org/linux/man-pages/man2/poll.2.html) – Basile Starynkevitch Jan 21 '21 at 21:53

1 Answers1

2

do the other threads continue executing when a signal arrives

On Linux they do because a signal is only ever delivered to one thread. Unless the signal is SIGSTOP, which stops all threads of a process. See man signal(7) and man pthreads(7) for more details (ignore LinuxThreads info related to old threads implementation).

Although POSIX does not require that, so these details are OS specific.

Maxim Egorushkin
  • 131,725
  • 17
  • 180
  • 271
  • 1
    This is not OS-specific but required by POSIX, which specifies clearly how signal delivery interacts with threads and that signal handlers interrupt the thread that receives the signal, not the process. – R.. GitHub STOP HELPING ICE Dec 28 '17 at 13:58
  • @R.. POSIX spec does specify how signals are generated and delivered, true. However, it does not specify in enough details how signal delivery to one thread affects other threads of execution (it must not affect other threads) - there is no such requirement. – Maxim Egorushkin Dec 28 '17 at 14:02
  • @R.. In other words, it could stop all threads while invoking a signal handler, and still be a POSIX-compliant implementation, wouldn't it? – Maxim Egorushkin Dec 28 '17 at 14:12
  • No. I don't see where you think you're getting that. – R.. GitHub STOP HELPING ICE Dec 28 '17 at 14:25
  • @R.. What POSIX requirement such an implementation would break then? – Maxim Egorushkin Dec 28 '17 at 14:45
  • Would changing the behaviour of SIGSTOP (with signal() from signal.h) in the main thread still stop the execution of the secondary threads when SIGSTOP arrives? – 27C256 Dec 28 '17 at 16:36
  • @27C256 From `man signal(7)`: _The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored._ – Maxim Egorushkin Dec 28 '17 at 17:54
  • 1
    @MaximEgorushkin: (1) signal delivery in a particular thread, and (2) requirement that threads (in same or different processes) behave as if they execute concurrently, i.e. that failure of one to make forward progress doesn't observably cause others not to make forward progress. – R.. GitHub STOP HELPING ICE Dec 29 '17 at 00:41