On Oct 15, 2012, at 3:11 PM, Richard Oudkerk email@example.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 Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas