Date: Mon, 17 Feb 2014 11:24:21 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: [CFT] new sendfile(2) Message-ID: <F56AE9A0-3649-4D4B-B8A5-1CFF3CC3B6B5@FreeBSD.org> In-Reply-To: <20140217111635.GL26785@glebius.int.ru> References: <20140217111635.GL26785@glebius.int.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Feb 2014, at 11:16, Gleb Smirnoff <glebius@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? =20 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...=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F56AE9A0-3649-4D4B-B8A5-1CFF3CC3B6B5>