Reading the Proactor pattern paper, specifically this part:
I/O Completion Ports in Windows NT: The Windows NT operating system implements the Proactor pattern. Various
Asynchronous Operationssuch as accepting new network connections, reading and writing to files and sockets, and transmission of files across a network connection are supported by Windows NT. The operating system is theAsynchronous Operation Processor. Results of the operations are queued up at the I/O completion port (which plays the role of theCompletion Dispatcher).The UNIX AIO Family of Asynchronous I/O Operations: On some real-time POSIX platforms, the Proactor pattern is implemented by the
aiofamily of APIs [9]. These OS features are very similar to the ones described above for Windows NT. One difference is that UNIX signals can be used to implement a truly asynchronousCompletion Dispatcher(the Windows NT API is not truly asynchronous).
What does it mean that Unix Signals can be used to implement “truly” asynchronous and that Windows NT API is not truly async? What makes it truly?
3
Here it just means that while the I/O operations themselves may be asynchronous, the completion events are dispatched synchronously in Windows (ie, when you check the completion port).
UNIX signals are asynchronous in the sense that they can interrupt your existing thread of control, invoke a signal handler in its own context, and then resume your normal execution.
In practice it’s often easier to use ppoll/pselect/sigtimedwait or some other synchronous method, rather than trying to do something both useful and async-signal-safe in a handler.
—
NB. Whether this is more “truly” asynchronous isn’t really an interesting question, because it just devolves into a “no true Scotsman” argument about the One True Meaning of Asynchrony.
All that matters is that the original authors considered asynchronous operations with asynchronous delivery of completions “more asynchronous” than asynchronous operations with synchronous delivery of completions.
3