06.01.2011 23:11, Sylvain Hellegouarch kirjoitti:
2011/1/6 Alex Grönholm <alex.gronh...@nextday.fi
<mailto:alex.gronh...@nextday.fi>>
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.
Since I wrote that piece of code, I guess I ought to chime in. First
of all, the code isn't part of CherryPy, simply it's one idea to
provide WebSocket to CherryPy. Considering WebSocket bootstraps on
HTTP but once that's done, it's just a raw socket with bits and pieces
on top, I wanted to find a way not to block CherryPy from serving
other requests once a WebSocket handshake had been performed. The idea
was simply to detach the socket from the worker thread once the
handshake had been performed. Then the application had a socket at
hand and this particular instance, I simply decided to use asyncore to
loop through those sockets aside from the CherryPy HTTP server. In
effect, you end up with asyncore for WS sockets and CherryPy for any
HTTP serving but from within one single process, using CherryPy's main
loop.
By large this is not a generic solution for implementing async in WSGI
but a specific example on how one can have both threads and an async
loop playing together. It's merely a proof of concept :)
Yes, this is how I figured it too. In the end, what really matters is
that code that doesn't get a dedicated thread has to be designed a
little differently. The purpose of this discussion is to come up with a
standard interface for such applications. I'd also like to explore the
possibility of incorporating such a mechanism in PEP 444, provided that
it does not complicate the implementation too much. Otherwise, a
separate specification may be necessary.
Hope that clarifies that piece of code.
--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
_______________________________________________
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
