From dev-return-19401-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Nov 14 23:43:56 2007 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 30620 invoked from network); 14 Nov 2007 23:43:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Nov 2007 23:43:55 -0000 Received: (qmail 81925 invoked by uid 500); 14 Nov 2007 23:43:42 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 81869 invoked by uid 500); 14 Nov 2007 23:43:42 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 81858 invoked by uid 99); 14 Nov 2007 23:43:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Nov 2007 15:43:42 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.40.195.232] (HELO verdesmares.com) (209.40.195.232) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Nov 2007 23:43:31 +0000 Received: from endora.local (unknown [201.21.162.101]) by verdesmares.com (Postfix) with ESMTP id 6E7DB4E58AB5; Wed, 14 Nov 2007 23:41:30 +0000 (UTC) Message-ID: <473B87A4.3020405@apache.org> Date: Wed, 14 Nov 2007 21:41:24 -0200 From: Davi Arnaut User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= CC: Aaron Bannert , Apache Portable Runtime Developers List Subject: Re: sendfile(2) misbehaves when header iovecs are specified References: <3CDF9687-11F8-4F1D-95E3-8875E6D94C4F@apple.com> <473A4F00.8000707@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Wilfredo S=E1nchez Vega wrote: > More from the networking team: >=20 > """ > With regard's to Aaron's comments above, the return value is as =20 > expected. The "len" parameter specifies the number of bytes for the =20 > header (if any) and the (possibly partial) contents of the file. In =20 > this case, it is 200,000, meaning the entire 80,000 bytes header plus = > 120,000 of the file contents, followed by the trailer, which is 90,029 = =20 > bytes, will be sent. The total bytes sent is therefore 290,029 bytes = > (80,000 + 120,000 + 90,029). It implies that 80,000 bytes of the file = =20 > contents did not get sent; only the first 120,000 bytes did. >=20 > So, to elaborate this, on input "len" implies the maximum number of =20 > bytes in the header and/or file to be sent. It does not control the =20 > trailer whatsoever; if a trailer exists, all of it will be sent. If =20 > "len" is 0, all of the header and/or file will be sent before the =20 > trailer (all of it, always) finally gets sent. On output, "len" =20 > specifies the total number of bytes sent. >=20 > I agree the man page is not clear about this and should be modified. > """ >=20 > This looks to agree with what you are seeing. Correct? >=20 Yes. Thanks. -- Davi Arnaut