[Python-ideas] Async API: some code to review

[Kristján Valur Jónsson]

> -----Original Message-----
> From: gvanrossum at gmail.com [mailto:gvanrossum at gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 31. október 2012 15:37
> To: Kristján Valur Jónsson
> Cc: Richard Oudkerk; python-ideas at python.org
> Subject: Re: [Python-ideas] Async API: some code to review
> 
> Ok, this is a good point: the more you can do without having to go through
> the main loop again the better.
> 
> I already took this to heart in my recent rewrites of recv() and
> send() -- they try to read/write the underlying socket first, and if it works,
> the task isn't suspended; only if they receive EAGAIN or something similar do
> they block the task and go back to the top.

Yes, this is possible for non-blocking style IO.   However, for IO architectures that are based on completions, you can't always mix and match.
On windows, for example it is complicated to do because of how AcceptEx works.  I recall socket properties, overlapped property and other things interfering.
I also recall testing the use of first trying non-blocking IO (for accept and send/recv) and then resorting to an IOCP call.  If I recall correctly, the added overhead of trying  a non-blocking call for the usual case of it failing was detrimental to the whole exercise.  the non-blocking IO calls took non-trivial time to complete.

The approach of having multiple "threads" doing accept also avoids the delay required to dispatch the request from the accepting thread to the worker thread.
 
> In fact, Listener.accept() does the same thing -- meaning the loop can go 
> This is also one of the advantages of yield-from; you *never* go back to the
> end of the ready queue just to invoke another layer of abstraction.


My experience with this stuff is of course based on stackless/gevent style programming, so some of it may not apply :)
Personally, I feel that things should just magically work, from the programmer's point of view, rather than have to manually leave a trace of breadcrumbs through the stack using "yield" constructs.  But that's just me.

K