Re: [PATCH] Bindings for ‘sendfile’

[Mark H Weaver]

Thien-Thi Nguyen <address@hidden> writes:

> 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.

I acknowledge that it might be useful to add a lower-level interface for
'sendfile', perhaps called 'sendfile-some', analogous to the R6RS
'get-bytevector-some'.  We can still do that.  However, I continue to
believe that 'sendfile' should do what its name implies, and what 99% of
users will want and expect.

The alternative would most likely result in the vast majority of code
written using 'sendfile' to be sporadically unreliable.  Even Ludovic
had trouble getting the loop right, and we all know that he's an
exceptionally talented and careful hacker.

Regarding the proposed low-level interface (which I will call
'sendfile-some' for now), I have a question: can it actually be used to
write a robust asynchronous server?  Is it guaranteed to never block for
more than a short time?  I don't know the answer.  If the answer is
"no", then it seems to me that this would eliminate the most compelling
reason for a 'sendfile-some' API.

Or how about the other potential use case you gave: to keep stats on how
much is sent per "chunk".  What is the meaning of "chunk"?  If so, is
sendfile(2) guaranteed to return once for each chunk?  If not, then what
is the meaning of the statistics you would gather?

     Regards,
       Mark