[Web-SIG] WSGI and sendfile()

[Phillip J. Eby]

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.