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 --]
next prev parent 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).