[Web-SIG] some questions about the write callable
Manlio Perillo
manlio_perillo at libero.it
Tue Oct 16 12:15:16 CEST 2007
Phillip J. Eby ha scritto:
> At 10:06 PM 10/15/2007 +0200, Manlio Perillo wrote:
>> 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 which case, your write() implementation will need to loop until all
> the data hits the OS-level buffers.
>
It seems that this is not possible with Nginx, but I will investigate
this problem better, since it is the best solution.
>
>> 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
> first place.
>
You are right, but this is only required by a "real" streaming
application (one that does not have an "end").
Even if an application need to serve, as an example, a file of about 100
MB, buffering should not be a problem (and the Nginx buffering model is
efficient).
I'm not even sure if HTTP 1.1 allows an "infinite" stream.
>
>> 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.
>
Ok, thanks
Manlio Perillo
More information about the Web-SIG
mailing list