[Python-ideas] An alternate approach to async IO

[Trent Nelson]

On Wed, Nov 28, 2012 at 11:57:29AM -0800, Richard Oudkerk wrote:
> On 28/11/2012 7:23pm, Trent Nelson wrote:
> >      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.)
> >
> >          Trent.
> 
> That api is fairly similar to what is in the proactor branch of tulip 
> where you can write
> 
>      for event in proactor.poll(timeout):
>          # process event
> 
> But why use a use a thread pool just to take items from one thread safe 
> (FIFO) queue and put them onto another thread safe (LIFO) queue?

    I'm not sure how "thread pool" got all the focus suddenly.  That's
    just an implementation detail.  The key thing I'm proposing is that
    we reduce the time involved in processing incoming IO requests.

    Let's ignore everything pre-Vista for the sake of example.  From
    Vista onwards, we don't even need to call GetQueuedCompletionStatus,
    we simply tell the new thread pool APIs which C function to invoke
    upon an incoming event.

    This C function should do as little as possible, and should have a
    small a footprint as possible.  So, no calling CPython, no GIL
    acquisition.  It literally just processes completed events, copying
    data where necessary, then doing an interlocked list push of the
    results, then that's it, done.

    Now, on XP, AIX and Solaris, we'd manually have a little thread
    pool, and each thread would wait on GetQueuedCompletionStatus(Ex)
    or port_get().  That's really the only difference; the main method
    body would be identical to what Windows automatically invokes via
    the thread pool approach in Vista onwards.

        Trent.