From: ludo@gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw@netris.org>
Cc: Andy Wingo <wingo@igalia.com>, 30066@debbugs.gnu.org
Subject: bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports
Date: Thu, 11 Jan 2018 22:02:29 +0100 [thread overview]
Message-ID: <87po6gnm6y.fsf@gnu.org> (raw)
In-Reply-To: <87fu7cf9wk.fsf@netris.org> (Mark H. Weaver's message of "Thu, 11 Jan 2018 14:55:07 -0500")
Hello,
Mark H Weaver <mhw@netris.org> skribis:
> ludo@gnu.org (Ludovic Courtès) writes:
[...]
>> + if (SCM_UNBUFFEREDP (port) && (avail < max_buffer_size))
>> + {
>> + /* PORT is unbuffered. Read as much as possible from PORT. */
>> + size_t read;
>> +
>> + bv = scm_c_make_bytevector (max_buffer_size);
>> + scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS (bv),
>> + avail, cur, avail);
>> +
>> + read = scm_i_read_bytes (port, bv, avail,
>> + SCM_BYTEVECTOR_LENGTH (bv) - avail);
>
> Here's the R6RS specification for 'get-bytevector-some':
>
> "Reads from BINARY-INPUT-PORT, blocking as necessary, until bytes are
> available from BINARY-INPUT-PORT or until an end of file is reached.
> If bytes become available, 'get-bytevector-some' returns a freshly
> allocated bytevector containing the initial available bytes (at least
> one), and it updates BINARY-INPUT-PORT to point just past these
> bytes. If no input bytes are seen before an end of file is reached,
> the end-of-file object is returned."
>
> By my reading of this, we should block only if necessary to ensure that
> we return at least one byte (or EOF). In other words, if we can return
> at least one byte (or EOF), then we must not block, which means that we
> must not initiate another 'read'.
Indeed. So perhaps the condition above should be changed to:
if (SCM_UNBUFFEREDP (port) && (avail == 0))
?
> Out of curiosity, is there a reason why you're using an unbuffered port
> in your use case?
It’s to implement redirect à la socat:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17af5d51de7c40756a4a39d336f81681de2ba447
Thanks,
Ludo’.
next prev parent reply other threads:[~2018-01-11 21:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 15:02 bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports Ludovic Courtès
2018-01-10 15:59 ` Ludovic Courtès
2018-01-10 16:32 ` Andy Wingo
2018-01-10 16:58 ` Nala Ginrut
2018-01-10 17:26 ` Andy Wingo
2018-01-10 17:43 ` Nala Ginrut
2018-01-11 14:34 ` Ludovic Courtès
2018-01-11 19:55 ` Mark H Weaver
2018-01-11 21:02 ` Ludovic Courtès [this message]
2018-01-11 21:55 ` Mark H Weaver
2018-01-12 9:01 ` Andy Wingo
2018-01-12 10:15 ` Ludovic Courtès
2018-01-12 10:33 ` Andy Wingo
2018-01-13 20:53 ` Ludovic Courtès
2018-02-16 13:19 ` 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=87po6gnm6y.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=30066@debbugs.gnu.org \
--cc=mhw@netris.org \
--cc=wingo@igalia.com \
/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).