From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Bindings for =?utf-8?B?4oCYc2VuZGZpbGXigJk=?= Date: Tue, 09 Apr 2013 22:34:14 +0200 Message-ID: <8738uz78ah.fsf@zigzag.favinet> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1365539519 21292 80.91.229.3 (9 Apr 2013 20:31:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Apr 2013 20:31:59 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 09 22:32:01 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 1UPfCy-0000Jr-HB for guile-devel@m.gmane.org; Tue, 09 Apr 2013 22:32:00 +0200 Original-Received: from localhost ([::1]:38564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPfCy-0005E6-5n for guile-devel@m.gmane.org; Tue, 09 Apr 2013 16:32:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPfCu-0005Dw-Qu for guile-devel@gnu.org; Tue, 09 Apr 2013 16:31:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPfCs-0002PM-IO for guile-devel@gnu.org; Tue, 09 Apr 2013 16:31:56 -0400 Original-Received: from smtp207.alice.it ([82.57.200.103]:34190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPfCs-0002Nl-8h for guile-devel@gnu.org; Tue, 09 Apr 2013 16:31:54 -0400 Original-Received: from zigzag.favinet (79.7.154.109) by smtp207.alice.it (8.6.060.15) id 51239AD707902C20 for guile-devel@gnu.org; Tue, 9 Apr 2013 22:31:52 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1UPfFJ-0000US-IC for guile-devel@gnu.org; Tue, 09 Apr 2013 22:34:25 +0200 In-Reply-To: <8761zvagt0.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 09 Apr 2013 17:02:03 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.103 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:16209 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () ludo@gnu.org (Ludovic Court=C3=A8s) () 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=E2=80=99t want to use sendfile(2) in the first place. Fourth, =E2=80=98write=E2=80=99, =E2=80= =98put-bytevector=E2=80=99, 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 =E2=80=98sendfile/all=E2=80=99 can be i= mplemented in terms of a =E2=80=98sendfile/non-looping=E2=80=99 but not the other way aro= und. 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-byteve= ctor=E2=80=99 being others). Unlike the others, however, there is still opportunity for change. =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlFke0oACgkQZwMiJEyAdQLb9QCgipZNiDKkEuHeS6SDTmxM5GKQ lnQAoMhdDqeTGyKoVi5yqchQ05MKwcLD =yBkD -----END PGP SIGNATURE----- --=-=-=--