Hi. The only feature that remains to implement for nginx mod_wsgi is the write callable.
The WSGI spec says: """In other words, before write() returns, it must guarantee that the passed-in string was either completely sent to the client, or that it is buffered for transmission while the application proceeds onward.""" With Nginx it can happen that the passed-in string cannot be completely sent to the client, since the socket can returns an EAGAIN. In this case Nginx will buffer the data and it will send the buffer to the client when the socket is ready. This is fully supported by nginx mod_wsgi, when the application returns a generator, since nginx mod_wsgi will suspend the execution of the application until the previous buffer has been entirely written to the client. Unfortunately, this is not possible with the write callable. This means that Nginx will try to send the data to the client, *only* when the write function is called. In other words, the transmission may become stalled if the application blocks and a previous passed-in string is in a nginx buffer. I don't understand why WSGI explicitly says '*must not* delay', instead of a 'should not delay'. There is another, more interesting, problem, however. As far as I can understand, WSGI does not explicitly forbids an application to call the write callable from a separate thread. This means that, in theory, this is allowed. Is this true? How many applications, if any, do this? Since Nginx is not thread safe, this *cannot* be supported, really. If a new WSGI 1.1 spec is going to be released, I hope that it will be more friendly with asynchronous servers without threads support. Thanks Manlio Perillo _______________________________________________ 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
