[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