wepoll

Actually that’s not totally accurate. The native IO model in the Win32 subsystem, I/O completion ports, is indeed completion based. But the NT kernel does have a scalable readiness model too, limited to sockets, that people have used to build an epoll(). See: https://github.com/piscisaureus/wepoll. This is used by e.g. deno and node.

People confuse IOCP with Windows' Overlapped I/O. kqueue supports completion notifications; it all depends on the semantics of the event filter and its flags. Likewise for epoll. For example, both kqueue and epoll support pollable I/O completion notifications for AIO, which is the the analogous Unix API for Overlapped I/O. (Similarly, people conflate implementation details with architecture, such as when people explain that AIO isn't like Overlapped I/O by describing how AIO and Overlapped I/O is implemented, without explaining how the API necessarily makes it so.) The benefit of IOCP and Overlapped I/O on Windows isn't the design. The benefit is that it comes complete out of the box, whereas on Linux and *BSD you either need to roll your own or supplement inconsistent kernel interfaces that people tend to avoid. But both IOCP and Overlap

It uses an ioctl that boils down to 'an overlapped version of poll()'. So the call doesn't block - instead when an event like POLLIN or POLLOUT happens, a completion is posted to the completion port. Call this overlapped-poll function on every monitored socket individually so you don't inherit poll()s scalability problems. See https://github.com/piscisaureus/wepoll/blob/437fb2f24ce197b4... This is as much of an explanation I can type on my phone - I'll add more detail to the wepoll readme later.

Shameless(-ish) plug: https://github.com/piscisaureus/wepoll is not a fat abstraction layer but it could help with windows support.