[Python-ideas] An alternate approach to async IO
trent at snakebite.org
Wed Nov 28 01:15:14 CET 2012
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
(That's the theory, at least.)
More information about the Python-ideas