Nicolas Williams wrote:
Why should sendfile work that way? The manpage doesn't say that it does.
It has been a while since I looked at it, but I think that there are some things in the man page that are incorrect and other things that are just omitted. These constraints were essentially added by escalation creep. That is, there have been bugs reported by customers that ultimately resolved by saying that sendfile was working the way it was supposed to and it was up to the user to prevent the problems.
I know that one case was the removal of the directory locking. I know that the containing directory can be locked when files are being accessed by the system. Since the duration of a sendfile call is indeterminate and arbitrarily long, it was deemed unacceptable to have a directory locked essentially forever, so that locking was removed. Alas, I do not know why directories are locked in the first place, so I don't know what the ramifications of this are, but whatever they are, the suer is supposed to prevent them from taking place.
Another issue is that with some common idioms of sendfile usage the user loop that calls sendfile can become infinite if the file being read is modified during the sendfile call. The result of that escalation was "don't call it that way, or don't modify the file". That one originally caused sendfile to hang and be un-interruptible, but it was changed to always allow sendfile to be interruptible and then to return instead of hang. But then some programs would call it again anyway.
To make matters even worse, in order to keep the blockfiles the same size in FTP, the usage of sendfile in ftpd is to call it repeatedly with the pointers such that each sendfile call only sends one block and then returns. Since the point of sendfile was to trade a bit more setup time and then not have to do context switches into the kernel, letting the kernel handle the looping, this is the worse of both worlds. Longer set up with the same number of context switches, and weird locking to boot.
-- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ networking-discuss mailing list [email protected]
