This is awesome! I have to make time to understand in more detail how it works and what needs to change in the platform-independent API -- I want to get to the point where the *only* thing you change is the pollster/proactor (both kind of lame terms :-). I am guessing that the socket operations (or the factory for the transport class) needs to be made part of the pollster; the Twisted folks are telling me the same thing.
FWIW, I've been studying other event loops. It's interesting to see the similarities (and differences) between e.g. the tulip eventloop, pyftpd's ioloop, Tornado's IOLoop, and 0MQ's IOLoop. The latter two look very similar, except that 0MQ makes the poller pluggable, but generally there are lots of similarities between the structure of all four. Twisted, as usual, stands apart. :-)
On Sat, Nov 3, 2012 at 2:20 PM, Richard Oudkerk email@example.com wrote:
On 02/11/2012 11:59pm, Guido van Rossum wrote:
Working code or it didn't happen. (And it should scale too.)
I have some (mostly) working code which replaces tulip's "pollster" classes with "proactor" classes for select(), poll(), epoll() and IOCP. See
The IOCP proactor does not support ssl (or ipv6) so main.py does not succeed in downloading from xkcd.com using ssl. Using the other proactors it works correctly.
The basic interface for the proactor looks like
class Proactor: def recv(self, sock, n): ... def send(self, sock, buf): ... def connect(self, sock, address): ... def accept(self, sock): ... def poll(self, timeout=None): ... def pollable(self): ...
recv(), send(), connect() and accept() initiate io operations and return futures. poll() returns a list of ready futures. pollable() returns true if there are any outstanding operations registered with the proactor. You use a pattern like
f = proactor.recv(sock, 100) if not f.done(): yield from scheduling.block_future(f) res = f.result()
Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas