[Python-ideas] An alternate approach to async IO

[Trent Nelson]

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.

        Trent.