22.05.2012 10:38, Sylvain Hellegouarch kirjoitti:
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.
It's also a hack that violates the WSGI spec. It's also not usable
through reverse proxying or FCGI/SCGI.
--
- 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/alex.gronholm%40nextday.fi
_______________________________________________
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
