On Fri, 22 Sep 2006 15:03:29 -0400 "Markus Mottl" <markus.mottl@xxxxxxxxx> wrote: > 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). sendfile() as far as I know should behave the same as send(). > 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. Partial send is not an error, it could be caused by premature close from the other end as well. Therefore, the application should not expect errno to be set. The application needs to do another write/send/sendfile to force continuation and error detection. > 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 > -- Stephen Hemminger <shemminger@xxxxxxxx> - 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
