[quotemstr]

Windows does have signals! It just splits them into a few facilities. POSIX "synchronous" signals correspond to SEH exceptions and can be handled roughly the same way --- except that signals have process global handlers and Windows has thread-local ones, because the glibc people are sticks in the mud and are hostile to any attempt to make signals suck less.

For asynchronous signals, like SIGINT, Windows create a new thread out of thin air to deliver your app a notification. That's not really all that much better than a signal from a concurrency perspective.

Windows even has APCs, which are like regular signals that are delivered only at explicit system call boundaries.

Every operating system needs some mechanism to tell a process to do something. Windows has evolved an approach that isn't all that different from Unix signal handling.

[cryptonector]

Spawning a new thread to handle a signal is much better than preemption: you then have no concerns about async-signal-safety that aren't plain old thread-safety concerns. I'd much rather have thread-safety constraints than async-signal-safety constraints.

[quotemstr]

Sort of. At least you can mask signals. I agree that threads are probably better overall, but I don't think it's a huge difference.

[Vogtinator]

Linux can do that as well, see SIGEV_THREAD.

[quotemstr]

Only for AIO, which few use.

[andreyv]

You can spawn a thread manually and use the POSIX sigwait() function.

[quotemstr]

That won't stop the process-wide registered signal handler working and it won't do anything about being able to reliably handle synchronous signals.