[Python-ideas] The async API of the future: Reactors
Richard Oudkerk
shibturn at gmail.com
Mon Oct 15 15:11:07 CEST 2012
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.
--
Richard
More information about the Python-ideas
mailing list