Hi, it seems to me that the "sendfile" system call is not well-specified. The documentation (man page) does (deliberately?) not mention what happens if "sendfile" e.g. gets interrupted by a signal, if the file to be sent gets truncated during execution, or if a timeout occurs writing to a socket (i.e. if SO_SNDTIMEO is set). I found more details on how sendfile is supposed to behave under such circumstances in the following article: http://www.linuxjournal.com/article/6345 If I have correctly understood the above article combined with what the man page says, "sendfile" should do one of the following: 1) return -1 on error, in which case "errno" will be set accordingly. 2) return the requested number of sent bytes (-> success). 3) return a lower number of sent bytes if at least a partial execution was possible. I expected "errno" to be set accordingly in case 3) so that one can find out why "sendfile" could not finish. If "errno" were zero (= success) then, according to the article the file must have been truncated during execution, which may not necessarily be an error for the user. All of the above would make perfect sense to me, because it would allow me to distinguish between all cases. But when I tried to find out what my kernel (2.6.17-1.2174_FC5) actually does when I force these events (timeouts, truncation, signals), the results are pretty much useless to determine what happened. In my tests the kernel always returned a lower number of sent bytes than requested when one of these events occurred, which is what I expected. But "errno" was always set to "success", with the exception of timeouts. The latter return success for partial transfers unless I perform the call to "sendfile" three times in a row. The last call, probably due to then full send buffers, returns -1, and "errno" gets set to EAGAIN (which I'd prefer seeing already for the first call). This behaviour does not allow me implement case 3) correctly, because results are ambiguous. Is the current implementation of "sendfile" incomplete, is my kernel buggy, or are there any hidden reasons why "sendfile" should behave in this way? Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
