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