PEP 444 and asynchronous support, continued

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PEP 444 and asynchronous support, continued

Alex Grönholm-3
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
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 and asynchronous support, continued

Glyph Lefkowitz
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
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 and asynchronous support, continued

Alex Grönholm-3
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
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com