I didn't dive past the links you dropped, but reading the doc comment makes it seem like the call is using `poll` (as an alternative to `select` for FD size reasons.) It's well recognized that the polling model of `select` and `poll` are slow and it was specifically this problem that led to the framing of the C10K problem. The solution is to use an async style of programming which is what libuv and other wrappers offer (piggybacking off `epoll` on Linux.)
Interestingly enough, polling is still preferred in some cases of low-latency networking, because the overhead of NIC interrupts can become significant under high utilization.
Of course in those cases you're running on bare-metal with kernel bypass networking, so there's no user<->kernel switch like in poll
The issue with select(2)/poll(2) (and for that matter WaitForMultipleObjects()) is that you are passing huge datastructure across userspace/kernel boundary with each call. There are various alternative platform specific implementations of what in the end is still polling that place the set of interesting FDs on the kernel side and thus make the whole thing significantly faster. That is what libev/libevent/libuv abstracts away in portable manner.
The programming style is essentially same for a program that uses select(2) directly. (If you do not count various anti-patterns that are common in GUI applications which do networking)
It’s been many many years since I’ve done low level multiplexing but I think epoll() is the no longer quite so new hotness?
Ah I see libuv is a cross platform lib. I’d probably use that for production code, but it’s still really valuable to work with the low level API enough to understand it.
Yeah epoll is what libuv calls on Linux. And agreed I think it's very valuable to try and use epoll or equivalent yourself at least once to understand what's happening.
