From owner-freebsd-current@FreeBSD.ORG Mon Feb 17 11:24:33 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7BFDD98; Mon, 17 Feb 2014 11:24:33 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B64A214E5; Mon, 17 Feb 2014 11:24:33 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1HBOSMo087792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 11:24:31 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: [CFT] new sendfile(2) From: David Chisnall In-Reply-To: <20140217111635.GL26785@glebius.int.ru> Date: Mon, 17 Feb 2014 11:24:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140217111635.GL26785@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1827) 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:24:34 -0000 On 17 Feb 2014, at 11:16, Gleb Smirnoff 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...=