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