On 17 Feb 2014, at 11:16, Gleb Smirnoff <gleb...@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?  


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...
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to