From owner-freebsd-current@FreeBSD.ORG  Thu Jul 11 19:04:04 2013
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 94070DDF;
 Thu, 11 Jul 2013 19:04:04 +0000 (UTC)
 (envelope-from scottl@samsco.org)
Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57])
 by mx1.freebsd.org (Postfix) with ESMTP id 48D991FAD;
 Thu, 11 Jul 2013 19:04:04 +0000 (UTC)
Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57])
 (authenticated bits=0)
 by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r6BIfklB084661;
 Thu, 11 Jul 2013 12:41:46 -0600 (MDT)
 (envelope-from scottl@samsco.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: hacking - aio_sendfile()
From: Scott Long <scottl@samsco.org>
In-Reply-To: <20130711095615.GM91021@kib.kiev.ua>
Date: Thu, 11 Jul 2013 11:41:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <648164F3-17CC-4629-8890-296FF3E642F8@samsco.org>
References: <CAJ-Vmo=icr6bda+WMNUarc3WbdqJ+MdauX6kByxxdTx8oSovBg@mail.gmail.com>
 <20130711061753.GK91021@kib.kiev.ua>
 <CAJ-VmomFcZv6_uhpy6ShBzL21=Fqw7_y2xE2oYGod2T=Z5Qgpg@mail.gmail.com>
 <20130711093630.GL91021@kib.kiev.ua>
 <CAJ-Vmo=ic_KuaaE2avvbX3JE=R25nuRyyAQpEmFrZRp7T9y9qg@mail.gmail.com>
 <20130711095615.GM91021@kib.kiev.ua>
To: Konstantin Belousov <kostikbel@gmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: Adrian Chadd <adrian@freebsd.org>,
 freebsd-current <freebsd-current@freebsd.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 19:04:04 -0000


On Jul 11, 2013, at 2:56 AM, Konstantin Belousov <kostikbel@gmail.com> =
wrote:

> On Thu, Jul 11, 2013 at 02:39:00AM -0700, Adrian Chadd wrote:
>> On 11 July 2013 02:36, Konstantin Belousov <kostikbel@gmail.com> =
wrote:
>>=20
>>> No, it is not disk I/O which is problematic there. It is socket I/O
>>> e.g. wait for the socket buffers lomark in the kern_sendfile() which
>>> causes unbounded sleep. Look for the sbwait() call, both in the
>>> kern_sendfile() itself, and in the pru_send methods of the =
protocols,
>>> e.g. in sosend_generic(). The wait scope controlled by the other =
side of
>>> connection and allow it to completely block the aio subsystem.
>>>=20
>>> Disk I/O is supposed to finish in the finite time.
>>=20
>> Even if the destination socket is marked as NONBLOCK?
>=20
> You mean, would a sleep for the socket buffer space cause aio thread
> block is the socket is put in nonblocking mode ?  Or something else ?
>=20
> No, it would not block the thread. But I cannot consider the
> aio_sendfile(2) implementation useful if it requires non-blocking
> socket. Also, what about other thread changing the socket to blocking
> mode while sendfile is in flight ?

Just as with other aspects of sendfile, it's up to the caller to protect =
this kind
of state.  Objecting to aio_sendfile() simply for the reason you state =
is absurd
and against the design goals of sendfile.

Scott