[Web-SIG] PEP 444 and asynchronous support, continued

[Alex Grönholm]

17.01.2011 06:47, Glyph Lefkowitz kirjoitti:
> 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.
I'm already regretting saying anything about performance. Our tests were 
run with the Apache Benchmark (ab) against a "Hello World" type WSGI 
app. Certainly nothing special.
>> - 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.
Unfortunately you are wrong. Thread synchronization is not necessary for 
callbacks, but it is necessary for supporting the result() method, since 
other threads may be blocking on that 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 don't see how that follows from anything you've said above.
Asynchronous apps (save for gevent and the likes) can't use the standard 
wsgi.input since reading would block the event loop. Therefore an 
alternative input has to be provided, right? How would that work then? 
If something, say, wsgi.async_input was to be provided, what would it 
return from .read()? Futures? Deferreds?
>> 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.
Which leads to the problem I described above.
> 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.
It is my understanding that eventlet only runs on CPython. Am I mistaken?
>> 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.
That's what I've been saying. But that only holds true for 
gevent/eventlet. Twisted, for one, needs explicit support unless, as you 
said, is used through eventlet.
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi