[Python-ideas] An alternate approach to async IO

Trent Nelson trent at snakebite.org
Wed Nov 28 21:05:32 CET 2012

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


More information about the Python-ideas mailing list