Looks like the comment in src/sendfile.c
* Our sockets are never non-blocking, so that seems to me to say that
* the kernel will never return EAGAIN -- we will always either send
* the whole thing or get an error. Is that really true?
needs updating, since the socket was set to nonblocking in
dcc_connect_by_addr().
- Dan
p.s. We noticed this while tracking down the following problem:
On an x86_64 system running a 64 bit 2.6.12 kernel and a 32
bit version of distcc, things weren't working at all.
We used strace and tcpdump to observe distcc sending a 35198 byte file:
3037 sendfile(5, 3, [0], 35198) = 11041
3037 sendfile(5, 3, [0], 24157) = -1 EAGAIN (Resource temporarily
unavailable)
3037 sendfile(5, 3, [0], 24157) = 10136
3037 sendfile(5, 3, [0], 14021) = -1 EAGAIN (Resource temporarily
unavailable)
3037 sendfile(5, 3, [0], 14021) = 14021
tcpdump shows that after sending the first 11041
bytes, it sends them again. So the second sendfile hasn't advanced
the file pointer at all... which is exactly what you see in the output
of strace.
strace on a 32 bit system shows the offset incrementing nicely:
2396 sendfile(5, 3, [0], 37077) = 12782
2396 sendfile(5, 3, [12782], 24295) = -1 EAGAIN (Resource temporarily
unavailable)
2396 sendfile(5, 3, [12782], 24295) = 14480
2396 sendfile(5, 3, [27262], 9815) = -1 EAGAIN (Resource temporarily
unavailable)
2396 sendfile(5, 3, [27262], 9815) = 9815
Looks like it's a bug in 2.6.12; 2.6.14 has a little change in
arch/x86_64/ia32/sys_ia32.c:
- if (!ret && offset && put_user(of, offset))
+ if (offset && put_user(of, offset))
- Dan
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
