<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
06.01.2011 23:11, Sylvain Hellegouarch kirjoitti:
<blockquote
cite="mid:AANLkTimWJJJG+4B1j+_QTE1BXynwujyzU-m6kV5=oRUW@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">2011/1/6 Alex Grönholm <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:alex.gronholm@nextday.fi">alex.gronholm@nextday.fi</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
06.01.2011 20:02, Eric Larson kirjoitti:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
At Thu, 6 Jan 2011 13:03:15 +0000 (GMT),<br>
chris dent wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<snip><br>
On async:<br>
<br>
I agree with some others who have suggested that maybe
async should be<br>
its own thing, rather than integrated into a WSGI2. A
server could<br>
choose to be WSGI2 compliant or AWSGI compliant, or both.<br>
</snip><br>
</blockquote>
+1<br>
<br>
After seeing some of the ideas regarding how to add async
into a new<br>
version of WSGI, it isn't the specific problem the async
feature<br>
addresses in terms of WSGI servers. Is the goal is to
support long<br>
running connections? Are we trying to support WebSockets and
other<br>
long running connection interfaces? If that is the case,
async is a<br>
*technique* for handling this paradigm, but it doesn't
address the<br>
real problem. There are techniques that have sounded
reasonable like<br>
making available the socket such that a server can give it
to the<br>
application to do something use with it (here is an example
doing<br>
something similar with CherryPy - <a moz-do-not-send="true"
href="http://trac.defuze.org/browser/oss/ws4cp/ws4cp.py"
target="_blank">http://trac.defuze.org/browser/oss/ws4cp/ws4cp.py</a>).<br>
</blockquote>
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.</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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 :)</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:AANLkTimWJJJG+4B1j+_QTE1BXynwujyzU-m6kV5=oRUW@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>Hope that clarifies that piece of code.</div>
<div>-- </div>
</div>
- Sylvain<br>
<a moz-do-not-send="true" href="http://www.defuze.org">http://www.defuze.org</a><br>
<a moz-do-not-send="true" href="http://twitter.com/lawouach">http://twitter.com/lawouach</a><br>
</blockquote>
<br>
</body>
</html>