[Web-SIG] PEP 444 / WSGI 2 Async

[Sylvain Hellegouarch]

2011/1/6 Alex Grönholm <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 :)

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/20110106/f0921572/attachment.html>