I downvoted this because you provided no evidence either IOCP or kqueue were the one true solution, any evidence the epoll designer was even aware of the existence of kqueue, and if they were, whether it was relevant to his work at all.
There is no reference to the context behind rejecting a kqueue-like API (opinion was that it looks a lot like ioctl - very true)
There is no rationale for why IOCP or kqueue is obviously a better design for Linux compared to epoll etc etc.
But just chalk it up to NIH, because that is the easiest and cheapest explanation for just about anything.
FWIW in the context of network APIs before Kqueue, there was the then-standard STREAMS, and the decisionmaking that led to Linux having epoll is the same that led to it avoiding the tragedy that was STREAMS. But if Linux had STREAMS today and not epoll or kqueue, the people who'd cry NIH and not-following-standards today would instead by crying about how much STREAMS sucks, and why Linux doesn't do its own thing
> There is no rationale for why IOCP or kqueue is obviously a better design for Linux compared to epoll etc etc.
I can, I think, partially address this, though unfortunately in the negative.
My understanding of IOCP is that the model requires the following: if you want to, say, receive data on a socket, you supply the IOCP w/ a buffer/length. After some data has been received, the buffer and the amount received are returned to you.
The problem with this model is that the buffer is effectively locked up in kernel space until the I/O is complete. Compared to readiness-notifications (select() and derivatives, such as poll/epoll/kqueue), which can share the same receive buffer among all receiving sockets. (They might need to buffer things like partially received commands, but you can perhaps use a much smaller buffer there, and/or only allocate it in the event you require it.)
It has been a long time since I've done Windows programming, so please correct me if I've gotten the above wrong. But that's a fundamental difference and advantage that epoll/kqueue have over IOCP.
Now, I do think the IOCP model is very much conceptually simpler, and I would guess that it is easier to write correct IOCP code than epoll code, but at the expense of memory in some situations. But IOCP doesn't (I don't think) cover as many situations as epoll/kqueue.
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 Overlapped I/O are higher-level APIs than traditional Unix readiness notification. The problem on Windows is that there's nothing like epoll or kqueue, which is critically important when you're trying to write library code that works with different event models. (Even on Windows Overlapped I/O isn't always ideal, especially in libraries trying to avoid callbacks or support multi-threading strategies different than those dictated by Overlapped I/O). Windows does implement something equivalent to traditional Unix readiness notification internally--it's how IOCP and Overlapped I/O are implemented--but its unpublished and exceptionally opaque. See https://github.com/piscisaureus/wepoll
>My understanding of IOCP is that the model requires the following: if you want to, say, receive data on a socket, you supply the IOCP w/ a buffer/length. After some data has been received, the buffer and the amount received are returned to you.
And then you have a language with GC and you want a async IO, and your runtime becomes so messy with IOCP support, so you just use poll on windows, as many languages do. kqueue is fine, but messy and incomprehensible, and I don't see how is it fundamentally better than epoll with ET.
Everyone else (IOCP, kqueue, etc) solved this problem. And then, Linux created the famously broken epoll().