[Web-SIG] PEP 444 / WSGI 2 Async

[Alex Grönholm]

06.01.2011 23:11, Sylvain Hellegouarch kirjoitti:
>
>
> 2011/1/6 Alex Grönholm <alex.gronholm at nextday.fi 
> <mailto:alex.gronholm at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20110107/b12c2c57/attachment.html>