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).

-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
>


Mime
View raw message