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

[Rene Nejsum]

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'

/Rene


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