[Python-ideas] An alternate approach to async IO

Guido van Rossum guido at python.org
Wed Nov 28 21:15:22 CET 2012

On Wed, Nov 28, 2012 at 12:05 PM, Trent Nelson <trent at snakebite.org> wrote:
> On Wed, Nov 28, 2012 at 07:59:04AM -0800, Guido van Rossum wrote:
>> OK, now I see. (I thought that was how everyone was using IOCP.
>> Apparently not?) However, the "short busy wait" worries me. What if
>> your app *doesn't* get a lot of requests?
>     From my response to Richard's concern re: busy waits:
>     Oooer, that's definitely not what I had in mind.  This is how I
>     envisioned it working (think of events() as similar to poll()):
>         with aio.events() as events:
>             for event in events:
>                 # process event
>                 ...
>     That aio.events() call would result in an InterlockedSListFlush,
>     returning the entire list of available events.  It then does the
>     conversion into a CPython event type, bundles everything into a
>     list, then returns.
>     (In reality, there'd be a bit more glue to handle an empty list
>      a bit more gracefully, and probably a timeout to aio.events().
>      Nothing should involve a spinlock though.)
>> Isn't the alternative to have a "thread pool" with just one thread,
>> which runs all the Python code and gets woken up by IOCP when it is
>> idle and there is a new event? How is Trent's proposal an improvement?
>     I don't really understand this suggestion :/  It's sort of in line
>     with how IOCP is used currently, i.e. "let me tell you when I'm
>     ready to process events", which I'm advocating against with this
>     idea.

Well, but since the proposal also seems to be to keep all Python code
in one thread, that thread still has to say when it's ready to process
events. So, again, what's the big deal? Maybe we just need benchmarks
showing events processed per second for various configurations...

--Guido van Rossum (python.org/~guido)

More information about the Python-ideas mailing list