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, 16 Apr 2013 22:14:47 +0200 Message-ID: <87txn6z0zs.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> <87ip3p1j7b.fsf@zigzag.favinet> <87y5citp2z.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 1366143151 10855 80.91.229.3 (16 Apr 2013 20:12:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2013 20:12:31 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Apr 16 22:12:35 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 1USCEy-0001NT-Vx for guile-devel@m.gmane.org; Tue, 16 Apr 2013 22:12:33 +0200 Original-Received: from localhost ([::1]:51299 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USCEy-0007gQ-Ew for guile-devel@m.gmane.org; Tue, 16 Apr 2013 16:12:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USCEs-0007gE-Ts for guile-devel@gnu.org; Tue, 16 Apr 2013 16:12:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USCEr-0007fP-DO for guile-devel@gnu.org; Tue, 16 Apr 2013 16:12:26 -0400 Original-Received: from smtp207.alice.it ([82.57.200.103]:36178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USCEp-0007eR-D5; Tue, 16 Apr 2013 16:12:23 -0400 Original-Received: from zigzag.favinet (79.50.64.172) by smtp207.alice.it (8.6.060.15) id 51239AD708A9D143; Tue, 16 Apr 2013 22:12:20 +0200 Original-Received: from ttn by zigzag.favinet with local (Exim 4.72) (envelope-from ) id 1USCHM-0005XS-IL; Tue, 16 Apr 2013 22:15:00 +0200 In-Reply-To: <87y5citp2z.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Tue, 16 Apr 2013 18:31:00 +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:16263 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () ludo@gnu.org (Ludovic Court=C3=A8s) () Tue, 16 Apr 2013 18:31:00 +0200 Thien-Thi Nguyen skribis: > 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. Just a note, this information is definitely not conveyed by the man page: sendfile() copies data between one file descriptor and another.=20= =20 [...] count is the number of bytes to copy between the file descriptors. Yes, that part is what you tell (request of) the OS, not what the OS tells (reports to) you. I think the manpage is not remiss here. Of course the return type hints at a write(2)-like interface, but the truth is that short writes had to be evidenced by experimental validation, so to speak. Well, i don't know what the truth is, but certainly it can be easy to misinterpret the sendfile(2) manpage if you don't take all of it into account. The major hint is actually: If offset is not NULL, then it points to a variable holding the file offset from which sendfile() will start reading data from in_fd. When sendfile() returns, this variable will be set to the offset of the byte following the last byte that was read. That is basically another way of saying that the syscall "does its best to send as much as possible, but does not guarantee sending everything". This is also conveyed in the general context of system programming, where an OS that guarantees a single-syscall full write of a possibly multi-gigabyte file is an OS that can be easily bludgeoned to death by mischievous (or simply misbehaving) userland programs, the eventual consequence being OS writers tend to avoid making such guarantees (especially for i/o, where the Real World is known to be Real Weird). Anyway, i hope Guile grows a =E2=80=98sendfile-some=E2=80=99 (or whatever) = so that i can adapt my programs to use it instead of the ttn-do =E2=80=98sendfile=E2=80= =99: http://www.gnuvola.org/software/ttn-do/ttn-do.html.gz#zz-sys-linux-gnu Until then, happy hacking! =2D-=20 Thien-Thi Nguyen GPG key: 4C807502 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlFtsTwACgkQZwMiJEyAdQKOsgCgjNPr3GV14U1jX3NIGOIgUKmA VOcAoJ/9Buea9Yglv0ZOIwt1lZ2ik45R =xjP+ -----END PGP SIGNATURE----- --=-=-=--