On Mon, Feb 17, 2014 at 11:24:21AM +0000, David Chisnall wrote:
D> >  Now for the new sendfile. The core idea is that sendfile()
D> > schedules the I/O, but doesn't wait for it to complete. It
D> > returns immediately to the process, and I/O completion is
D> > processed in kernel context. Unlike aio(4), no additional
D> > threads in kernel are created. The new sendfile is a drop-in
D> > replacement for the old one. Applications (like nginx) doesn't
D> > need recompile, neither configuration change. The SF_NODISKIO is
D> > ignored.
D> 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.
D> Wouldn't it be better to provide an aio_sendfile() that would deliver 
completion notifications via the normal aio mechanism?  

This race actually exists with the classical sendfile and existed
ever since. While pages are in socket buffer, and not yet sent
out wire, any modification to them would affect data sent.

To know when you can modify data you need to use SF_SYNC flag.
The flag should work with new sendfile as well, effectively
making it blocking on socket. I haven't tested this, but
should work.

Adrian have also committed the kqueue notification of SF_SYNC
event. This should work in combination with new sendfile, but
that hasn't been tested yet. This is going to be tested soon,
since we need this functionality.

Totus tuus, Glebius.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to