4 ms·

Why does the signal handler have to interrupt a thread? Why doesn't the OS just create a new thread to run the signal handler in? This would avoid this whole re

• teacup50 12y ago
  The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?
  • fulafel 12y ago
    Only a subset of signals come from mapping CPU faults to signals, the so-called synchronous signals. This example was about SIGINT coming from the usual source (Ctrl-C from terminal). It's actually possible to handle it in a thread using existing semantics without kqueue or signalfd: block SIGINT from all threads except your dedicated SIGINT-handling thread.
    • teacup50 12y ago
      That requires that you have control over all threads, which is just not something that can be guaranteed with modern operating systems and libraries that regularly spawn their own threads. Thread-interrupting delivery of signals is necessary in a world where you're relying on that interruption of your single thread; a replacement that worked for the async signals is useful, but distinct from the needs of sync signal handling.
    • kelnos 12y ago
      That doesn't actually work 100%: signals can be sent to the process as a whole or to a specific thread. The SIGINT-handling thread will be able to handle signals sent to the process, but not to any other thread of the program.
• Athas 12y ago
  Threads are fairly expensive - you have to allocate and map a new stack, as well as a bunch of bookkeeping data structures in the kernel. While the kernel could of course start an auxillary thread at program initialisation, and re-use it for all signals, this does complicate the runtime environment a bit. And what happens if the signal-handling-thread triggers a signal? I suppose the Unix tradition encourages giving the user the ability to centralise signal handling in a thread if he wishes (using kpoll or signalfd or whatever you want), but not forcing any overhead upon the program.
• deleted 12y ago
  [deleted]