apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wilfredo Sánchez Vega <wsanc...@apple.com>
Subject Re: sendfile(2) misbehaves when header iovecs are specified
Date Wed, 14 Nov 2007 00:23:43 GMT
   OK, I've sent the bug back with this comment/request.


On Nov 13, 2007, at 2:22 PM, Aaron Bannert wrote:

> Hmm, that's not the behavior I am seeing with Leopard's sendfile. I  
> am seeing the value-result parameter come back with the total byes  
> in the 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,  
> and a trailer of 90,029 bytes (from APR's test/sendfile.c test). The  
> input to the *len param starts as 200,000 (the size of the file) and  
> after the call it comes back set as 290,029. If you're saying that  
> the *len return result should be the total bytes sent (headers +  
> file + trailers) then the result should have been 370,049. Note that  
> in this example, the other end of the connection appears to have  
> received at least 119980 bytes.
> Could we get a detailed explanation of what all the expected inputs  
> and outputs are for sendfile in Leopard() (and if it's different  
> that previous versions, the same for those would help too).
> -aaron
> On Nov 13, 2007, at 1:06 PM, Wilfredo Sánchez 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  
>> I hear from you.
>> 	-wsv

View raw message