Sturla Molden wrote:
But it uses a thread-pool that polls the registered wait objects, so the overhead (with respect to latency) will still be O(n).
I'm not sure exactly what you mean by "polling" here. I'm pretty sure that *none* of the mechanisms we're talking about here (select, poll, kqueue, IOCP, WaitForMultipleWhatever, etc) indulge in busy-waiting while looping over the relevant handles. They all ultimately make use of hardware interrupts to wake up a thread when something interesting happens.
The scaling issue, as I understand it, is that select() and WaitForMultipleObjects() require you to pass in the entire list of fds or handles on every call, so that there is an O(n) setup cost every time you wait.
A more scaling-friendly API would let you pre-register the set of interesting objects, so that the actual waiting call is O(1). I believe this is the reason things like epoll, kqueue and IOCP are considered more scalable.