[Python-ideas] The async API of the future: Reactors

[Guido van Rossum]

[Responding to yet another message in the original thread]

On Thu, Oct 11, 2012 at 9:45 PM, Trent Nelson <trent at snakebite.org> wrote:
> On Thu, Oct 11, 2012 at 07:40:43AM -0700, Antoine Pitrou wrote:
>> On Wed, 10 Oct 2012 20:55:23 -0400 Trent Nelson <trent at snakebite.org> wrote:
>> >     You could leverage this with kqueue and epoll; have similar threads
>> >     set up to simply process I/O independent of the GIL, using the same
>> >     facilities that would be used by IOCP-processing threads.

>> Would you really win anything by doing I/O in separate threads, while
>> doing normal request processing in the main thread?

>     If the I/O threads can run independent of the GIL, yes, definitely.
>     The whole premise of IOCP is that the kernel takes care of waking
>     one of your I/O handlers when data is ready.  IOCP allows that to
>     happen completely independent of your application's event loop.
>
>     It really is the best way to do I/O.  The Windows NT design team
>     got it right from the start.  The AIX and Solaris implementations
>     are semantically equivalent to Windows, without the benefit of
>     automatic thread pool management (and a few other optimisations).
>
>     On Linux and BSD, you could get similar functionality by spawning
>     I/O threads that could also run independent of the GIL.  They would
>     differ from the IOCP worker threads in the sense that they all have
>     their own little event loops around epoll/kqueue+timeout.  i.e. they
>     have to continually ask "is there anything to do with this set of
>     fds", then process the results, then manage set synchronisation.
>
>     IOCP threads, on the other hand, wait for completion of something
>     that has already been requested.  The thread body implementation is
>     significantly simpler, and no synchronisation primitives are needed.

>> That said, the idea of a common API architected around async I/O,
>> rather than non-blocking I/O, sounds interesting at least theoretically.

(Oh, what a nice distinction.)

>     It's the best way to do it.  There should really be a libevent-type
>     library (libiocp?) that leverages IOCP where possible, and fakes it
>     when not using a half-sync/half-async pattern with threads and epoll
>     or kqueue on Linux and FreeBSD, falling back to processes and poll
>     on everything else (NetBSD, OpenBSD and HP-UX (the former two not
>     having robust-enough pthread implementations, the latter not having
>     anything better than select or poll)).

In which category does OS X fall?

>     However, given that the best IOCP implementations are a) Windows by
>     a huge margin, and then b) Solaris and AIX in equal, distant second
>     place, I can't see that happening any time soon.
>
>     (Trying to use IOCP in the reactor fashion described above for epoll
>      and kqueue is far more limiting than having an IOCP-oriented API
>      and faking it for platforms where native support isn't available.)

How close would our abstracted reactor interface have to be exactly
like IOCP? The actual IOCP API calls have very little to recommend
them -- it's the implementation and the architecture that we're after.
But we want it to be able to use actual IOCP calls on all systems that
have them.

>> Maybe all those outdated Snakebite Operating Systems are useful for
>> something after all. ;-P

>     All the operating systems are the latest version available!
>     In addition, there's also a Solaris 9 and HP-UX 11iv2 box.
>     The hardware, on the other hand... not so new in some cases.

-- 
--Guido van Rossum (python.org/~guido)