I think the right choice depends on the kind of signal: 1. SigPipe and similar synchronous signals can be disabled. You already get an error code from the IO o

I think the right choice depends on the kind of signal: 1. SigPipe and similar synchronous signals can be disabled. You already get an error code from the IO operation anyways, so they're redundant. It's kind of useful for traditional unix command line tools, since it'll just terminate the process when the output pipe gets closed. 2. SigInt and similar messages from other processes, should be handled via signalfd or the self-pipe trick. That way they look like any other asynchronous message that might come in via a pipe or socket. 3. SigSegV and other severe errors can just terminate the process Windows chose a different approach: SigSegV is a (structured) exception which causes unwinding. Unwinding has its own set of challenges, especially as language boundaries are crossed. SigInt calls a registered callback on a separate thread, so the handler is not subjected in the same limitations as a signal of an existing thread, and can use the same synchronization primitives as any other multi threaded code. GUI applications have a message queue per window, which is used for similar purposes (sometimes it makes sense for a console application to create a hidden window to receive such messages).