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: Sun, 14 Apr 2013 12:48:40 +0200 Message-ID: <87ip3p1j7b.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> <8738uz78ah.fsf@zigzag.favinet> <87d2u2bp93.fsf@tines.lan> 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 1365936390 12133 80.91.229.3 (14 Apr 2013 10:46:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2013 10:46:30 +0000 (UTC) Cc: guile-devel@gnu.org To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 14 12:46:34 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 1URKSA-0006zB-C1 for guile-devel@m.gmane.org; Sun, 14 Apr 2013 12:46:34 +0200 Original-Received: from localhost ([::1]:42275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URKS9-0001rs-QW for guile-devel@m.gmane.org; Sun, 14 Apr 2013 06:46:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URKS5-0001rk-UP for guile-devel@gnu.org; Sun, 14 Apr 2013 06:46:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1URKS4-0005Tp-UM for guile-devel@gnu.org; Sun, 14 Apr 2013 06:46:29 -0400 Original-Received: from smtp209.alice.it ([82.57.200.105]:44076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1URKS4-0005Te-JS for guile-devel@gnu.org; Sun, 14 Apr 2013 06:46:28 -0400 Original-Received: from zigzag.favinet (95.245.75.83) by smtp209.alice.it (8.6.060.15) id 511CF61A0909C83D; Sun, 14 Apr 2013 12:46:13 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1URKUN-0004CB-Sz; Sun, 14 Apr 2013 12:48:51 +0200 In-Reply-To: <87d2u2bp93.fsf@tines.lan> (Mark H. Weaver's message of "Wed, 10 Apr 2013 07:26:32 -0400") 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.105 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:16241 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () 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 =E2=80=98O_NONBLOCK=E2=80=99, = 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 =E2=80=98sendfile=E2=80=99 not de= viate 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? =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlFqiY0ACgkQZwMiJEyAdQLgogCfcMo49s7LyjVlIzqBZyPN71tm /B8AnRGWWUFRR0EgnXz0vNwwlRQi7ltq =l53c -----END PGP SIGNATURE----- --=-=-=--