() Mark H Weaver () 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