apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@codemass.com>
Subject Re: sendfile(2) misbehaves when header iovecs are specified
Date Tue, 13 Nov 2007 22:22:18 GMT
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).


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