On 03/25/2009 05:51 PM, Daniel Kahn Gillmor wrote: > Well, in this case, nothing went wrong (since the whole file was > transferred across the socket). When i get a chance, i'll try to modify > my code to do this over a network socket instead of a UNIX socket, and > listen to it from socat on another machine to see if i can get the whole > file that way. It seems not unlikely that the different socket domains > (AF_UNIX and AF_INET) would have different code paths in the kernel. Interesting. I've just updated my hack of a simple sendfile() test [0], and it seems that it has the same result over a TCP connection as over a local UNIX-domain socket, even pulling from CIFS. The setup: /mnt is a cifs mount. The listener is set up on a different machine with address $RECV_IP: socat TCP4-LISTEN:3333 STDIO | sha1sum The sender tests the sha1sum of the file (both on the cifsmount, and on a local filesystem), and then sends the cifsmounted file to the receiver: cp /mnt/bigfile.ogg /tmp sha1sum /mnt/bigfile.ogg /tmp/bigfile.ogg ./sendfiletester /mnt/bigfile.ogg $RECV_IP 3333 the result: * sendfile returns EOVERFLOW, but sets *offset to the total number of bytes requested to be sent. * the data is transferred cleanly across the network, and all three sha1sums match. The above is even true if i simulate network congestion by throttling the throughput significantly at the receiver's end by running the following command instead: trickle -s -d 500 TCP4-LISTEN:3333 STDIO | sha1sum I this case, the invocation of sendfile() hangs while the client is hanging, but it invariably returns first, with the same EOVERFLOW, and with *offset set the same way. And the full file still gets through :/ So i'm stumped: apache-mpm-worker is doing something different than my test harness is doing, for sure. Maybe it's a threading issue? --dkg [0] http://cmrg.fifthhorseman.net/browser/trunk/test/sendfile
Attachment:
signature.asc
Description: OpenPGP digital signature