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

Rene Nejsum rene at stranden.com
Mon Oct 15 16:11:00 CEST 2012

On Oct 15, 2012, at 3:11 PM, Richard Oudkerk <shibturn at gmail.com> wrote:

> On 12/10/2012 11:49pm, Guido van Rossum wrote:
>>>> >>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.)
>> ...
>> 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.
> One could use IOCP or select/poll/... to implement an API which looks like
> class AsyncHub:
>    def read(self, fd, nbytes):
>        """Return future which is ready when read is complete"""
>    def write(self, fd, buf):
>        """Return future which is ready when write is complete"""
>    def accept(self, fd):
>        """Return future which is ready when connection is accepted"""
>    def connect(self, fd, address):
>        """Return future which is ready when connection has succeeded"""
>    def wait(self, timeout=None):
>        """Wait till a future is ready; return list of ready futures"""
> A reactor could then be built on top of such a hub.

So in general alle methods are async, even the wait() could be async if
it returned a Furure, this way all methods would be of the same concept.

I like this as a general API for all types of connections and all underlying OS'


> --
> Richard
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas

More information about the Python-ideas mailing list