08.01.2011 23:16, P.J. Eby kirjoitti:
As a semi-proof-of-concept, I whipped these up:
http://peak.telecommunity.com/DevCenter/AsyncWSGISketch
It's an expanded version of my Coroutine concept, updated with sample
server code for both a synchronous server and an asynchronous one.
The synchronous "server" is really just a decorator that wraps a WSGI2
async app with futures support, and handles pauses by simply waiting
for the future to finish.
The asynchronous server is a bit more hand-wavy, in that there are
some bits (clearly marked) that will be server/framework dependent.
However, they should be straightforward for a specialist in any given
async framework to implement.
What is *most* handwavy at the moment, however, is in the details of
precisely what one is allowed to "yield to". I've written the
sketches dealing only with PEP 3148 futures, but sockets were also
proposed, and IMO there should be simple support for obtaining data
from wsgi.input.
However, even this part is pretty easy to extrapolate: both server
examples just add more type-testing branches in their
"base_trampoline()" function, copying and modifying the existing
branches that deal with futures.
The entire result is surprisingly compact -- each server weighed in at
about 40 lines, and the common Coroutine class used by both adds
another 60-something lines.
In the limit case, it appears that any WSGI 1 server could provide an
(emulated) async WSGI2 implementation, simply by wrapping WSGI2 apps
with a finished version of the decorator in my sketch.
Or, since users could do it themselves, this would mean that WSGI2
deployment wouldn't be dependent on all server implementers
immediately turning out their own WSGI2 implementations.
True async API implementations would be more involved, of course --
using a WSGI2 decorator on say, Twisted's WSGI1 implementation, would
give you no performance advantages vs. using Twisted's APIs directly.
But, as soon as someone wrote a Twisted-specific translation of my
async-server sketch, such an app would be portable.
More discussion is still needed, but at this point I'm convinced the
concept is *technically* feasible. (Whether there's enough need in
the "market" to make it worthwhile, is a separate question.)
I'm a bit unclear as to how this will work with async. How do you
propose that an asynchronous application receives the request body?
_______________________________________________
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/alex.gronholm%40nextday.fi
_______________________________________________
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
