06.01.2011 20:02, Eric Larson kirjoitti:
At Thu, 6 Jan 2011 13:03:15 +0000 (GMT),
chris dent wrote:
<snip>
On async:
I agree with some others who have suggested that maybe async should be
its own thing, rather than integrated into a WSGI2. A server could
choose to be WSGI2 compliant or AWSGI compliant, or both.
</snip>
+1
After seeing some of the ideas regarding how to add async into a new
version of WSGI, it isn't the specific problem the async feature
addresses in terms of WSGI servers. Is the goal is to support long
running connections? Are we trying to support WebSockets and other
long running connection interfaces? If that is the case, async is a
*technique* for handling this paradigm, but it doesn't address the
real problem. There are techniques that have sounded reasonable like
making available the socket such that a server can give it to the
application to do something use with it (here is an example doing
something similar with CherryPy -
http://trac.defuze.org/browser/oss/ws4cp/ws4cp.py).
The primary idea behind asynchronous servers/applications is the ability
to efficiently serve a huge number of concurrent connections with a
small number of threads. Asynchronous applications tend to be faster
because there is less thread context switching happening in the CPU. Any
application that runs on top of a web server that allocates less threads
to the application than the number of connections has to be quick to
respond so as not to starve the thread pool or block the event loop.
This is true regardless of whether nonblocking I/O or some other
technique is used. I'm a bit unclear as to how else you would do this.
Care to elaborate on that? I looked at the Cherrypy code, but I couldn't
yet figure that out.
Just to summarize, I'm for making async something else while finding a
way to support long running connections in WSGI outside of adopting a
particular technique a potentially viable goal.
Just my $.02 on the issue.
Eric Larson
_______________________________________________
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
