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