some questions about the write callable

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-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

Manlio Perillo ha scritto:
> 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.
> 

A correction.
Nginx will not buffer the data, it will ignore successive
write requests.

The buffering must be done by the application.

For the moment I will raise an exception when the data
cannot be 
completely written to the client (IMHO this does not
forbidden the WSGI 
spec, but, of course, it is not very useful).




Regards  Manlio Perillo
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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.


>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.


>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.

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

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
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com