[Web-SIG] WSGI and sendfile()
Phillip J. Eby
pje at telecommunity.com
Mon Aug 23 18:02:11 CEST 2004
At 10:37 AM 8/23/04 +0100, Andrew Eland wrote:
>The WSGI draft seems to be progressing well, it's great to see some effort
>at standardisation in this area.
>
>I had a couple of thoughts:
>
>If write() allowed an object implementing the fileno() method as a
>parameter, then an implementation is free to use the sendfile() syscall to
>efficiently send the entire contents of a file descriptor to the client.
>I don't know whether others think this is useful enough functionality to
>warrant the extra implementation complexity.
>If you ignore the possible efficiency gains, and sendfile() is emulated by
>the implementation, it still reduces the amount of code that needs to be
>written to serve a static file.
If the use case is just to send *one* file, this could be supported by the
application returning a file object; we could amend the spec to indicate
that if the returned iterable has a 'fileno()' attribute, the server *may*
use OS facilities to read data directly from the descriptor, but must still
call the iterable's close() method, rather than closing the file descriptor.
>There's an as asymmetry in streaming. Although the use of iterators allows
>a single-threaded implementation to stream a response to many clients
>simultaneously with something like select(), it doesn't work the other way
>around. If the only access to the request body is via the wsgi.input
>stream, all reads will be blocking. Although processing many large uploads
>simultaneously isn't such a common use case when developing websites, it
>can be when developing web services.
Perhaps it should be mentioned that the server *is* allowed to buffer the
input stream to e.g. a temporary file, *before* invoking the application.
More information about the Web-SIG
mailing list