[Web-SIG] some questions about the write callable

Manlio Perillo manlio_perillo at libero.it
Mon Oct 15 22:06:08 CEST 2007


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


More information about the Web-SIG mailing list