[Web-SIG] some questions about the write callable
Phillip J. Eby
pje at telecommunity.com
Tue Oct 16 00:27:49 CEST 2007
At 10:06 PM 10/15/2007 +0200, Manlio Perillo wrote:
>The only feature that remains to implement for nginx mod_wsgi is the
>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 which case, your write() implementation will need to loop until
all the data hits the OS-level buffers.
>In this case Nginx will buffer the data and it will send the buffer to
>the client when the socket is ready.
Note that the two choices are:
1. data is completely sent to the client
2. data is held in a buffer *such that transmission will continue
while the app runs*
Buffering the data but not sending it while the application continues
executing, is not a conformant option.
>I don't understand why WSGI explicitly says '*must not* delay', instead
>of a 'should not delay'.
Because the only reason for having write() or iteration blocks (vs
sending a single giant string) is to support interleaving the client
communication and some other computation, communication, or I/O.
Delay would negate the point of having the ability to stream in the
>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.
In theory, yes. In practice, we intended to document some
thread-affinity restrictions, and I do not believe that anybody is
trying to call write() from another thread.
>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.
Well, I hope that the *documentation* will be more friendly for
implementing gateways for such servers. It's doubtful that the
actual execution model would change much.
More information about the Web-SIG