Does running the self-pipe trick on a separate thread solve that issue? It seems like it's basically equivalent to signalfd (neither worse nor better, unless you're worried about platform-specific thread bugs): you end up with a signal mask on your main thread, but you also avoid EINTR on your main thread. Any possible pipe lockup just happens on the signal-handling thread, so the mainloop can keep running and eventually dequeue signals.
> Does running the self-pipe trick on a separate thread solve that issue? It seems like it's basically equivalent to signalfd (neither worse nor better, unless you're worried about platform-specific thread bugs): you end up with a signal mask on your main thread, but you also avoid EINTR on your main thread. Any possible pipe lockup just happens on the signal-handling thread, so the mainloop can keep running and eventually dequeue signals.
There's no need for threads. Set the pipe to non-blocking and ignore the write() error if it's EAGAIN/EWOULDBLOCK. See my response above for why dropping writes if a byte already exists in the pipe is okay.
Sure, but that doesn't solve the EINTR problem. If you accept signal-handler interruptions on threads where you actually do work, then you risk interrupting system calls on those threads, and even SA_RESTART isn't guaranteed to work all of the time. That's what a separate thread (or signalfd) wins you.
> Does running the self-pipe trick on a separate thread solve that issue?
Perhaps but then you're mixing signals and threads and you're in for a whole new world of hurt. :)
E.g. I've found that OSX does not always behave correctly when delivering signals to a process where one thread has blocked the signal but another hasn't, though I cannot remember the exact details. And of course on any system there is such a thing as signals addressed to a specific thread rather than a whole process (ptherad_kill()).
I've heard claims of badness with signals and threads, but I've failed to track down concrete problems -- I would really like to know what they are. Meanwhile I've heard of people successfully using dedicated signal-handling threads in production, at least on Linux.
I'm not really sure that thread-directed signals are in scope for the sorts of things where you must use signals (SIGINT, SIGTSTP, etc. from a terminal, SIGCHLD from child termination, etc.) Those should all be process-directed. If you design your own API that involves signals, then sure, but that's a problem of your own making.
