<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
In other words: The responsibility for the connection (and socket) is<br>
passed to the application.<br>
<br>
This works well with traditional threaded servers. The application can<br>
spawn a new worker thread, put the job into a queue or whatever and then<br>
return from the application callable, allowing the server thread to<br>
continue handling new connections. <br><br></blockquote></div><div><br></div>This is exactly how ws4py was implemented when using CherryPy for the HTTP server performing the handshake [1]. There&#39;s also a WSGI middleware [2] but it&#39;s heavily geared towards gevent and may not be reusable easily elsewhere I&#39;m afraid.<br clear="all">
<div><br></div>-- <br>- Sylvain<br><a href="http://www.defuze.org">http://www.defuze.org</a><br><a href="http://twitter.com/lawouach">http://twitter.com/lawouach</a><br>
<div><br></div><div>[1] <a href="https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/cherrypyserver.py">https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/cherrypyserver.py</a></div>
<div>[2] <a href="https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/wsgi/middleware.py">https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/wsgi/middleware.py</a></div>