After a weekend of experimentation with several asynchronous frameworks
including gevent, tornado and twisted (and writing one myself too), and
these are my findings so far:
- asynchronous socket implementations vary wildly across different
frameworks
- gevent is the fastest, tornado comes second while twisted is pretty slow
- twisted provides the most comprehensive support for implementing
protocols, while the other two mostly just provide low level support for
asynchronous sockets
- futures seem to have a significant overhead (from the thread
synchronization)
- gevent provides the easiest programming interface with greenlets,
since it pretty much lets you write asynchronous code as you would write
it synchronously
- gevent could make use of the regular, synchronous PEP 444 API by
monkey patching the socket library (through its import monkey;
monkey.patch_socket() call)
The significance of this for the Python web standards effort is that
providing an asynchronous API that works for the existing asynchronous
frameworks does not seem feasible. I'd love to see a solution for this
in the standard library, but gevent's monkey patching approach, while
convenient for the developer, cannot obviously work there. Before an
asynchronous WSGI API can be provided, this lower level problem needs to
be solved first. The crucial question is: is it possible to provide
gevent's level of convenience through the standard library, and if not,
what is the next best solution? I'd like to hear everyone's thoughts on
this (especially Guido's).
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
