Re: [PATCH] Bindings for ‘sendfile’

[Thien-Thi Nguyen]

() Mark H Weaver <address@hidden>
() Wed, 10 Apr 2013 07:26:32 -0400

   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?

I can't imagine why not, although i certainly don't pretend to be an
expert on async server programming.  My experience is mostly on the
client side, w/ Emacs as the front-end.  I would be surprised if
sendfile(2) is NOT used in robust asynchronous servers written in C.

   Is it guaranteed to never block for more than a short time?  I don't
   know the answer.

Me neither, although i think this depends on ‘O_NONBLOCK’, which is
established on open(2).

   If the answer is "no", then it seems to me that this would eliminate
   the most compelling reason for a 'sendfile-some' API.

Why?

   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?

I'd rather not get into particulars in this line of discussion, if you
don't mind, for lack of time.  Instead, i'll just ask you to try to
imagine a robust P2P architecture (every node as both client and server)
that does NOT care about flow control, and spew some philosophy here
(feel free to ignore)...

My reading of sendfile(2) is that it does its best to send as much as
possible, but does not guarantee sending everything.  What it does
succeed in sending, it reports to the caller.  The caller loops as
desired, after evaluating (in some caller-meaningful way) the returned
information.

All i desire is the semantics of a Scheme ‘sendfile’ not deviate from
that of the syscall sendfile(2); i judge not "implication of the name
for the statistical majority", only fidelity, when it comes to syscalls.

Control, not coddling, please -- why should C programmers have all the fun?

-- 
Thien-Thi Nguyen
GPG key: 4C807502

pgpUaB28BiSNH.pgp
Description: PGP signature