From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: [PATCH] Bindings for ‘sendfile’
Date: Tue, 09 Apr 2013 17:02:03 +0200 [thread overview]
Message-ID: <8761zvagt0.fsf@gnu.org> (raw)
In-Reply-To: 87r4ik5ciy.fsf@zigzag.favinet
Hi!
Thien-Thi Nguyen <ttn@gnuvola.org> skribis:
> () ludo@gnu.org (Ludovic Courtès)
> () Sun, 07 Apr 2013 21:53:26 +0200
>
> +In other cases, the libc function may send fewer bytes than
> +@var{count}---for instance because @var{out} is a slow or limited
> +device, such as a pipe. When that happens, Guile's @code{sendfile}
> +automatically retries until exactly @var{count} bytes were sent or an
> +error occurs.
>
> A short write is an opportunity for the caller to Do Something Else
> (i.e., go asynchronous). I think that is more useful than internalizing
> the looping. To accomodate both usage patterns, you could leave the
> low-level proc as-is (as-was :-D) and provide another proc that loops.
Well, I hesitated a lot. My initial inclination was to do what you say,
and let users handle the looping.
After a long discussion on IRC was Mark, I was mostly convinced that
leaving that to users is questionable.
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’t want to use sendfile(2) in the first
place. Fourth, ‘write’, ‘put-bytevector’, etc. also hide short writes.
My 4¢,
Ludo’.
next prev parent reply other threads:[~2013-04-09 15:02 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 [this message]
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
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=8761zvagt0.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@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).