[Python-ideas] The async API of the future

[Greg Ewing]

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.

-- 
Greg