On Sat, Nov 3, 2012 at 4:49 PM, Greg Ewing <<a>greg.ewing@canterbury.ac.nz</a>> wrote:<br>
> Sturla Molden wrote:<br>
>><br>
>> But it uses a thread-pool that polls the registered wait objects, so the<br>
>> overhead (with respect to latency) will still be O(n).<br>
><br>
><br>
> I'm not sure exactly what you mean by "polling" here. I'm<br>
> pretty sure that *none* of the mechanisms we're talking about<br>
> here (select, poll, kqueue, IOCP, WaitForMultipleWhatever, etc)<br>
> indulge in busy-waiting while looping over the relevant handles.<br>
> They all ultimately make use of hardware interrupts to wake up<br>
> a thread when something interesting happens.<br>
><br>
> The scaling issue, as I understand it, is that select() and<br>
> WaitForMultipleObjects() require you to pass in the entire list<br>
> of fds or handles on every call, so that there is an O(n) setup<br>
> cost every time you wait.<br>
><br>
> A more scaling-friendly API would let you pre-register the set<br>
> of interesting objects, so that the actual waiting call is<br>
> O(1). I believe this is the reason things like epoll, kqueue<br>
> and IOCP are considered more scalable.<br>
<br>
I've been thinking about this too. I can see the scalability issues with select(),  but frankly, poll(), epoll(), and even kqueue() all look similar in O() behavior to me from an API perspective. I guess the differences are in the kernel -- but is it a constant factor or an unfortunate O(N) or worse? To what extent would this be overwhelmed by overhead in the Python code we're writing around it? How bad is it to add extra register()/unregister() (or (modify()) calls per read operation?<span></span><br>
<br><br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
<br><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)<br>