
On Sat, Oct 23, 2010 at 11:04 PM, Gregory Collins
Michael Snoyman
writes: This does seem like the right approach. Just as fair warning: using an enumerator for serving files loses out on the possible optimization of a sendfile system call. Another possibility may be to keep a pool of file names to use as temporary files and keep rotating their usage. But I *do* think your approach is the correct one.
On unixy systems the "correct" approach traditionally would be to open the file, then unlink it before you send the data out the socket. When the file descriptor is closed, the link count goes to zero and the file goes away. Obviously this isn't portable though.
Besides portability, it doesn't fit in with the WAI request/response timeline. In WAI, the server won't start sending the response until the application returns it. Matt got around this problem by using the ResponseEnumerator constructor, which forces the server to run arbitrary code, but there's no such mechanism for the ResponseFile constructor. So I suppose two other possible approaches might be: * Extend the ResponseFile constructor to have a cleanup function. I don't really like this, as I don't think it's generally necessary. * Fork a thread just before returning the ResponseFile that sleeps for some amount of time (5 seconds should be *more* than ample) and then deletes the file. However, over all, I think Matt has the correct approach given the constraints involved. Michael