[Python-ideas] An alternate approach to async IO

[Trent Nelson]

On Tue, Nov 27, 2012 at 03:50:34PM -0800, Guido van Rossum wrote:
> On Tue, Nov 27, 2012 at 3:33 PM, Sturla Molden <sturla at molden.no> wrote:
> >
> > Den 27. nov. 2012 kl. 23:36 skrev Trent Nelson <trent at snakebite.org>:
> >
> >>
> >>    Right, but with things like interlocked lists, you can make that
> >>    CPython|background_IO synchronization barrier much more performant
> >>    than relying on GIL acquisition.
> >
> > You always need the GIL to call back to Python.  You don't need it for anything else.
> 
> You also need it for any use of an object, even INCREF, unless you
> know no other thread yet knows about it.

    Right, that's why I proposed using non-Python types as buffers
    whilst in the background IO threads.  Once the thread finishes
    processing the event, it pushes the necessary details onto a
    global interlocked list.  ("Details" being event type and possibly
    a data buffer if the event was 'data received'.)

    Then, when aio.events() is called, CPython code (holding the GIL)
    does an interlocked/atomic flush/pop_all, creates the relevant
    Python objects for the events, and returns them in a list for
    the calling code to iterate over.

    The rationale for all of this is that this approach should scale
    better when heavily loaded (i.e. tens of thousands of connections
    and/or Gb/s traffic).  When you're dealing with that sort of load
    on a many-core machine (let's say 16+ cores), an interlocked list
    is going to reduce latency versus 16+ threads constantly vying for
    the GIL.

    (That's the theory, at least.)

        Trent.