() l...@gnu.org (Ludovic Courtès) () Tue, 09 Apr 2013 17:02:03 +0200 After a long discussion on IRC was Mark, I was mostly convinced that leaving that to users is questionable.
User behavior in the wild is always questionable. :-D First, because one obviously expects the procedure to send the file, not just part of it. Second, those who did not forget to implement the loop can easily get it wrong. Third, if you really want to interleave I/O and computation, you probably don’t want to use sendfile(2) in the first place. Fourth, ‘write’, ‘put-bytevector’, etc. also hide short writes. Yes, the overall intent is to send all the file. However, it's not wise to assume caller doesn't want to keep stats (for example) on how much of the file is sent per chunk. That is not a heavy computation, but still quite valid. (Imagine an adaptive server that has write access to the kernel network and virtual memory subsystem knobs.) The same thinking applies to any internalized looping. The design principle to pursue is that the lowest level should leave the most control to the caller, w/o losing the essence of the functionality. [Insert quote from that wily programmer, A. Einstein, here. :-D] [Insert analogous "bufferbloat" problem, here.] (Of course, higher-level convenience interfaces are always welcome, once the possibility of control (by caller) is guaranteed.) Another way to think about it is: A ‘sendfile/all’ can be implemented in terms of a ‘sendfile/non-looping’ but not the other way around. So overall, i think hiding partial i/o is a mistake. This is just one instance of that, it seems (‘write’ and ‘put-bytevector’ being others). Unlike the others, however, there is still opportunity for change. -- Thien-Thi Nguyen GPG key: 4C807502
pgpLchJZ8HpcU.pgp
Description: PGP signature
