There are two scenarios - sendfile can't proceed immediately because all sfbuf space is exhausted, and sendfile can't proceed immediately because the page to be sent isn't in physical memory.
In both cases, we can have another process/thread call sendfile with the flag cleared, allowing sendfile to block as needed. This work is being done in the context of the Flash Web Server, which already had helper processes to perform all of the disk-related operations. These helpers use pipes/sockets to communicate back to the main process that a page has been loaded into memory (or that the page has been sent directly). We don't currently initiate async I/O's using a nonportable interface, but that's also a possibility.
-Vivek
John-Mark Gurney wrote:
[EMAIL PROTECTED] wrote this message on Sun, Oct 26, 2003 at 10:48 -0500:
We decided to avoid all mmap/mincore operations, and opted to instead add a flag to sendfile such that we can try sendfile and have it return an error (instead of blocking) when a page isn't in memory.
I was thinking about this myself, but how do you prevent spinning on the sendfile waiting for the page to become available? You have the send space to wait for on the socket, but there is no equivalent kqueue event to wait for when a page becomes available. Do you simply always spin on sendfile since the socket keeps returning available for writing?
I have a similar web server design that I wrote at the end of last year, and your paper brought to light to problems of sendfile, so I have been thinking of switching to async io, since there you can get completion status when the io completes.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
