[Python-ideas] The async API of the future

[Antoine Pitrou]

On Sat, 3 Nov 2012 12:47:53 +0100
Sturla Molden <sturla at 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.