On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote: > 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
That's certainly true. > - gevent is the fastest, tornado comes second while twisted is pretty slow Fastest at... what? If you have a WSGI benchmark for Twisted, could you contribute it in a form that we could use at <http://speed.twistedmatrix.com/> so that we can improve the situation? Thanks. > - futures seem to have a significant overhead (from the thread > synchronization) If there were some way to have tighter control over where the callbacks in add_done_callback were executed, thread synchronization might not be necessary. The module as currently specified does need to have a bit of overhead to deal with that, but the general concept doesn't. > 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 don't see how that follows from anything you've said above. > 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. gevent and eventlet don't need any special support from WSGI though. It's basically its own special kind of multithreading, with explicit context-switches, but from the application developer's perspective it's almost exactly the same as working with threads. The API can be the existing WSGI API. Twisted and Tornado and Marrow (and Diesel, if that were a thing that still existed) do need explicit APIs though, and it seems to me that there might be some value in that. For that matter, Eventlet can use Twisted as a networking engine, so actually you can already use Twisted asynchronously with WSGI that way. The whole point of having an asynchronous WSGI standard is to allow applications to be written such that they can have explicitly-controlled event-driven concurrency, not abstracted-over context switches in a convenience wrapper. > Before an asynchronous WSGI API can be provided, this lower level problem > needs to be solved first. I'm not even clear on what "lower level problem" you're talking about. If you're talking about interoperability between event-driven frameworks, I see it the other way around: asynchronous WSGI is a good place to start working on interoperability, not a problem to solve later when the rest of the harder low-level things have somehow been unified. (I'm pretty sure that's never going to happen.) > 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). gevent and eventlet already have things that will monkey patch the socket module that the standard library uses (for example: <http://eventlet.net/doc/patching.html>), so ... yes? And if this "level of convenience" is what you're aiming for (blocking calls with an efficient, non-threaded scheduler), again, you don't need async WSGI for that. _______________________________________________ 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
