OK, I've sent the bug back with this comment/request.
-wsv
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
smime.p7s
Description: S/MIME cryptographic signature
