[Python-ideas] The async API of the future: Reactors
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'
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas