[Web-SIG] Write buffering (was Re: WSGI uses)
Phillip J. Eby
pje at telecommunity.com
Fri Aug 20 18:04:12 CEST 2004
At 04:35 PM 8/19/04 -0700, tony at lownds.com wrote:
> >> If it's a second class citizen to the
> >>iterator why not force all applications to provide their own buffering?
> > I don't see what you mean about buffering.
>An application framework can provide its own write() very easily
>def app_framework(env, start_response):
> buffer = 
> write = buffer.append
> return buffer
Ah. But that doesn't allow *streaming* writes. The specific use case I
had in mind for using your write() idea was to allow frameworks that
currently allow streaming writes as a function/method invocation during the
request execution, to still work under WSGI.
In effect, 'write()' is a backward compatibility mechanism for existing
code that expects to be able to stream data to the client during request
execution, and is not currently written in the form of an
iterator/producer. (It's also an acceptable mechanism for small/fast
requests, and frameworks that normally buffer their I/O and would only call
'write()' once anyway.)
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*."
On the other hand, if I/O is single-threaded in that fashion, then the
server should be required to finish every write() before the write() call
returns. The write() function should only be allowed to buffer the data if
another thread is emptying the buffer continuously.
I'll add this to the spec, unless anybody knows of any other use cases for
either buffering or not buffering writes.
More information about the Web-SIG