From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Bindings for =?utf-8?B?4oCYc2VuZGZpbGXigJk=?= Date: Wed, 10 Apr 2013 07:26:32 -0400 Message-ID: <87d2u2bp93.fsf@tines.lan> References: <87ip4liufs.fsf@gnu.org> <878v5hbblk.fsf@tines.lan> <87obed2iqo.fsf@gnu.org> <87sj32rubt.fsf@inria.fr> <87r4ik5ciy.fsf@zigzag.favinet> <8761zvagt0.fsf@gnu.org> <8738uz78ah.fsf@zigzag.favinet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1365593223 29361 80.91.229.3 (10 Apr 2013 11:27:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Apr 2013 11:27:03 +0000 (UTC) Cc: guile-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 10 13:27:04 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UPtB9-0003Zn-QH for guile-devel@m.gmane.org; Wed, 10 Apr 2013 13:27:03 +0200 Original-Received: from localhost ([::1]:51995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPtB9-0006dY-Cq for guile-devel@m.gmane.org; Wed, 10 Apr 2013 07:27:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPtB4-0006ZL-Ub for guile-devel@gnu.org; Wed, 10 Apr 2013 07:27:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPtB3-0006Di-A4 for guile-devel@gnu.org; Wed, 10 Apr 2013 07:26:58 -0400 Original-Received: from world.peace.net ([96.39.62.75]:38781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPtB3-00069l-6e for guile-devel@gnu.org; Wed, 10 Apr 2013 07:26:57 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1UPtAl-00044y-D9; Wed, 10 Apr 2013 07:26:39 -0400 In-Reply-To: <8738uz78ah.fsf@zigzag.favinet> (Thien-Thi Nguyen's message of "Tue, 09 Apr 2013 22:34:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16214 Archived-At: Thien-Thi Nguyen writes: > Another way to think about it is: A =E2=80=98sendfile/all=E2=80=99 can be= implemented in > terms of a =E2=80=98sendfile/non-looping=E2=80=99 but not the other way a= round. > > So overall, i think hiding partial i/o is a mistake. This is just one > instance of that, it seems (=E2=80=98write=E2=80=99 and =E2=80=98put-byte= vector=E2=80=99 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