Re: [PATCH] Bindings for ‘sendfile’

[Thien-Thi Nguyen]

() address@hidden (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

pgpqYY4mbGAZ1.pgp
Description: PGP signature