Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The OS has to pause a thread that triggers a signal; how can it proceed if doing so would just segfault again?


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: