From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 11:32:55 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9041456F; Mon, 17 Feb 2014 11:32:55 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16A7115F7; Mon, 17 Feb 2014 11:32:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.8/8.14.8) with ESMTP id s1HBWrMB059506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Feb 2014 15:32:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.8/8.14.8/Submit) id s1HBWrNN059505; Mon, 17 Feb 2014 15:32:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 17 Feb 2014 15:32:53 +0400 From: Gleb Smirnoff To: David Chisnall Subject: Re: [CFT] new sendfile(2) Message-ID: <20140217113253.GM26785@glebius.int.ru> References: <20140217111635.GL26785@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:32:55 -0000 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> 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> 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.