Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 62978 invoked from network); 13 Nov 2007 22:24:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Nov 2007 22:24:01 -0000 Received: (qmail 65882 invoked by uid 500); 13 Nov 2007 22:23:47 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 65845 invoked by uid 500); 13 Nov 2007 22:23:47 -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 65834 invoked by uid 99); 13 Nov 2007 22:23:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2007 14:23:47 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.66.64.76] (HELO mailhost.clove.org) (208.66.64.76) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 13 Nov 2007 22:24:40 +0000 Received: (qmail 67701 invoked by uid 1014); 13 Nov 2007 14:23:20 -0800 Received: from [64.81.61.244] (HELO [10.0.1.2]) (64.81.61.244) (smtp-auth username aaron, mechanism plain) by clove.org (qpsmtpd/0.32) with ESMTP; Tue, 13 Nov 2007 14:23:19 -0800 Cc: Apache Portable Runtime Developers List Message-Id: From: Aaron Bannert To: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= In-Reply-To: <3CDF9687-11F8-4F1D-95E3-8875E6D94C4F@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: sendfile(2) misbehaves when header iovecs are specified Date: Tue, 13 Nov 2007 14:22:18 -0800 References: <3CDF9687-11F8-4F1D-95E3-8875E6D94C4F@apple.com> X-Mailer: Apple Mail (2.912) X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Check-By: clove.org X-Old-Spam-Status: No, hits=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,DKIM_POLICY_SIGNSOME,DK_POLICY_SIGNSOME Hmm, that's not the behavior I am seeing with Leopard's sendfile. I am =20= seeing the value-result parameter come back with the total byes in the =20= file plus the total size of the trailers, excluding the headers. For example, with a header of 80,000 bytes, a file of 200,000 bytes, =20 and a trailer of 90,029 bytes (from APR's test/sendfile.c test). The =20 input to the *len param starts as 200,000 (the size of the file) and =20 after the call it comes back set as 290,029. If you're saying that the =20= *len return result should be the total bytes sent (headers + file + =20 trailers) then the result should have been 370,049. Note that in this =20= example, the other end of the connection appears to have received at =20 least 119980 bytes. Could we get a detailed explanation of what all the expected inputs =20 and outputs are for sendfile in Leopard() (and if it's different that =20= previous versions, the same for those would help too). -aaron On Nov 13, 2007, at 1:06 PM, Wilfredo S=E1nchez Vega wrote: > Davi- > > Regarding this issue: > > http://people.apache.org/~davi/leopard-sendfile.c > > Our kernel folks say this isn't a bug: > > No, this is not a bug. Our sendfile(2) implementation is > similar to FreeBSD 4.x, where the 4th argument to the system > call (the value-result length parameter) includes the header > length. In FreeBSD 5.x, this length does not include the > header, but that is not the semantics followed by Mac OS X. > > Is this sufficient information? I've still got the bug open until =20= > I hear from you. > > -wsv >