[CFT] new sendfile(2)

[David Chisnall]

On 17 Feb 2014, at 11:16, Gleb Smirnoff <glebius at FreeBSD.org> wrote:

>  Now for the new sendfile. The core idea is that sendfile()
> schedules the I/O, but doesn't wait for it to complete. It
> returns immediately to the process, and I/O completion is
> processed in kernel context. Unlike aio(4), no additional
> threads in kernel are created. The new sendfile is a drop-in
> replacement for the old one. Applications (like nginx) doesn't
> need recompile, neither configuration change. The SF_NODISKIO is
> ignored.

Doesn't this introduce a race?  If I do a sendfile now, then I am at liberty to modify the underlying file as soon as it returns. With this version, I not only am not free to modify the file, I have no notification that it is finished so I can't ever safely use this call on a file that I might eventually modify.

Wouldn't it be better to provide an aio_sendfile() that would deliver completion notifications via the normal aio mechanism?  

David

P.S. If aio() is creating a new thread per request, rather than scheduling them from a pool, then that is also likely a bug.  The aio APIs were designed so that systems with DMA controllers could issue DMA requests in the syscall and return immediately, then trigger the notification in response to the DMA-finished interrupt.  There shouldn't need to be any kernel threads created to do this...