unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Bindings for ‘sendfile’
Date: Tue, 16 Apr 2013 22:14:47 +0200	[thread overview]
Message-ID: <87txn6z0zs.fsf@zigzag.favinet> (raw)
In-Reply-To: <87y5citp2z.fsf@gnu.org> ("Ludovic Courtès"'s message of "Tue, 16 Apr 2013 18:31:00 +0200")

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

() ludo@gnu.org (Ludovic Courtès)
() Tue, 16 Apr 2013 18:31:00 +0200

   Thien-Thi Nguyen <ttn@gnuvola.org> 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.  

      [...]

      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 ‘sendfile-some’ (or whatever) so that i can
adapt my programs to use it instead of the ttn-do ‘sendfile’:

http://www.gnuvola.org/software/ttn-do/ttn-do.html.gz#zz-sys-linux-gnu

Until then, happy hacking!

-- 
Thien-Thi Nguyen
GPG key: 4C807502

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2013-04-16 20:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 22:21 [PATCH] Bindings for ‘sendfile’ Ludovic Courtès
2013-03-21  0:17 ` Noah Lavine
2013-03-21  9:15   ` Ludovic Courtès
2013-03-21 10:04     ` Andrew Gaylard
2013-03-21 15:39     ` Noah Lavine
2013-03-21  3:45 ` Nala Ginrut
2013-03-21  4:50 ` Mark H Weaver
2013-03-21  5:24   ` Mark H Weaver
2013-03-21  9:40   ` Ludovic Courtès
2013-03-21  9:49     ` Andy Wingo
2013-03-21 10:10       ` Ludovic Courtès
2013-03-22 19:22     ` Mark H Weaver
2013-03-22 21:27       ` Ludovic Courtès
2013-03-24  5:04         ` Mark H Weaver
2013-03-25 12:55           ` Ludovic Courtès
2013-04-07 19:53     ` Ludovic Courtès
2013-04-09  8:33       ` Thien-Thi Nguyen
2013-04-09 15:02         ` Ludovic Courtès
2013-04-09 20:34           ` Thien-Thi Nguyen
2013-04-10 11:26             ` Mark H Weaver
2013-04-14 10:48               ` Thien-Thi Nguyen
2013-04-16 16:31                 ` Ludovic Courtès
2013-04-16 20:14                   ` Thien-Thi Nguyen [this message]
2013-04-17 12:52                     ` Ludovic Courtès
2013-04-17 15:18                       ` Thien-Thi Nguyen
2013-04-17 16:27                         ` Ludovic Courtès
2013-04-18  6:58                           ` Thien-Thi Nguyen
2013-04-10 20:56             ` Ludovic Courtès
2013-04-14 10:52               ` Thien-Thi Nguyen
2013-04-07 21:51   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87txn6z0zs.fsf@zigzag.favinet \
    --to=ttn@gnuvola.org \
    --cc=guile-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).