On Sat, 3 Nov 2012 12:47:53 +0100 Sturla Molden <sturla@molden.no> wrote:
Also, from what I read, the complexity of select.poll is O(n) with respect to file handles, so this should not be any worse (O(log n) katency wait, O(n) polling) I think.
epoll and kqueue are better than O(number of objects) though.
I know, they claim the wait to be about O(1). I guess that magic happens in the kernel.
They are not O(1), they are O(number of ready objects).
With IOCP on Windows there is a thread-pool that continuously polls the i/o tasks for completion. So I think IOCPs might approach O(n) at some point.
Well, I don't know about the IOCP implementation, but "continuously polling the I/O tasks" sounds like a costly way to do it (what system call would that use?). If the kernel cooperates, no continuous polling should be required.
That is depending on perspective :-)If threads are a simpler design pattern than IOCPs, the latter is a huge waste of work hours.
Er, the whole point of this discussion is to design a library so that the developer does *not* have to deal with IOCPs. As for "simpler design pattern", I think it's mostly a matter of habit. Writing a network daemon with Twisted is not difficult. And making multi-threaded code scale properly might not be trivial, depending on the problem. Regards Antoine.