[Web-SIG] Write buffering (was Re: WSGI uses)

[Phillip J. Eby]

At 11:13 AM 8/20/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Still, your comments have illustrated to me that there does need to be 
>>better definition of how flushing is expected to occur, although there is 
>>only one use case I can think of for it.  Specifically, the only time an 
>>application needs to ensure that all its pending output has been sent to 
>>the client, is when it is about to perform some lengthy calculation and 
>>is using "server push" to display a "please wait" screen before returning 
>>the real result.  In this case, if I/O is single-threaded (i.e. only 
>>happens when write() calls are made), and write() isn't guaranteed to be 
>>flushed (e.g. it's buffered and sent in blocks), then the application 
>>would need to have a way to say, "no, really, please send it *now*."
>
>I some environments (e.g., CGI) I don't believe there's any way to ensure 
>that the data gets sent immediately.  The buffering is rather opaque in 
>those cases.  So all we can do is try, we can't really guarantee that data 
>will be sent.

True enough.  I've not seen a problem with CGI myself, but I believe some 
CGI-based protocols (not FastCGI, but some clones of it) buffer entire 
requests no matter what you do.  WSGI servers or gateways that can't do 
streaming should document that fact.  Or perhaps there should be two 
compliance levels: WSGI Basic and WSGI Streaming.