> > > In other words: The responsibility for the connection (and socket) is > passed to the application. > > This works well with traditional threaded servers. The application can > spawn a new worker thread, put the job into a queue or whatever and then > return from the application callable, allowing the server thread to > continue handling new connections. > > This is exactly how ws4py was implemented when using CherryPy for the HTTP server performing the handshake [1]. There's also a WSGI middleware [2] but it's heavily geared towards gevent and may not be reusable easily elsewhere I'm afraid.
-- - Sylvain http://www.defuze.org http://twitter.com/lawouach [1] https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/cherrypyserver.py [2] https://github.com/Lawouach/WebSocket-for-Python/blob/master/ws4py/server/wsgi/middleware.py
_______________________________________________ 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
