[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