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? 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... _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
