From: Nala Ginrut <nalaginrut@gmail.com>
To: Andy Wingo <wingo@igalia.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, 30066@debbugs.gnu.org
Subject: bug#30066: 'get-bytevector-some' returns only 1 byte from unbuffered ports
Date: Thu, 11 Jan 2018 00:58:31 +0800 [thread overview]
Message-ID: <CAPjoZoeUvrAtNQLB7HxL0oXTQoK4p0v3cYX2A8f8aVMaG640FQ@mail.gmail.com> (raw)
In-Reply-To: <87fu7dptdn.fsf@igalia.com>
hi Andy and Ludo!
What if developers enabled suspendable-ports and set the port to non-blocking?
For example, in the non-blocking asynchronous server, I registered
read/write waiter for suspendable-ports. And save
delimited-continuations then yield the current task.
In this situation, get-bytevector-n! will read n bytes with several
times yielding by the registered read-writer, from the caller's
perspective, get-bytevector-n! will return n bytes finally no matter
how many times it's yielded.
But how about the get-bytevector-some? Should it block just once and
return the first time read m bytes then return?
Thanks!
On Thu, Jan 11, 2018 at 12:32 AM, Andy Wingo <wingo@igalia.com> wrote:
> On Wed 10 Jan 2018 16:59, ludo@gnu.org (Ludovic Courtès) writes:
>
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> As discussed on IRC, ‘get-bytevector-some’ returns only 1 byte from
>>> unbuffered ports:
>>
>> Here’s a tentative fix. WDYT?
>
> Thanks! Needs a little work though :) Comments inline.
>
>> --- a/libguile/ports.h
>> +++ b/libguile/ports.h
>> @@ -69,6 +69,7 @@ SCM_INTERNAL SCM scm_i_port_weak_set;
>> #define SCM_OPOUTPORTP(x) (SCM_OPPORTP (x) && SCM_OUTPUT_PORT_P (x))
>> #define SCM_OPENP(x) (SCM_OPPORTP (x))
>> #define SCM_CLOSEDP(x) (!SCM_OPENP (x))
>> +#define SCM_UNBUFFEREDP(x) (SCM_PORTP (x) && (SCM_CELL_WORD_0 (x) & SCM_BUF0))
>> #define SCM_CLR_PORT_OPEN_FLAG(p) \
>> SCM_SET_CELL_WORD_0 ((p), SCM_CELL_WORD_0 (p) & ~SCM_OPN)
>> #ifdef BUILDING_LIBGUILE
>
> Please guard this under #ifdef BUILDING_LIBGUILE.
>
>> @@ -487,16 +487,33 @@ SCM_DEFINE (scm_get_bytevector_some, "get-bytevector-some", 1, 0, 0,
>>
>> SCM_VALIDATE_BINARY_INPUT_PORT (1, port);
>>
>> - buf = scm_fill_input (port, 0, &cur, &avail);
>> - if (avail == 0)
>> + if (SCM_UNBUFFEREDP (port))
>> {
>> - scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F);
>> - return SCM_EOF_VAL;
>> + size_t read;
>> +
>> + bv = scm_c_make_bytevector (4096);
>> + read = scm_i_read_bytes (port, bv, 0, SCM_BYTEVECTOR_LENGTH (bv));
>> +
>> + if (read == 0)
>> + return SCM_EOF_VAL;
>> + else if (read < SCM_BYTEVECTOR_LENGTH (bv))
>> + return scm_c_shrink_bytevector (bv, read);
>> + else
>> + return bv;
>> }
>> + else
>> + {
>> + buf = scm_fill_input (port, 0, &cur, &avail);
>> + if (avail == 0)
>> + {
>> + scm_port_buffer_set_has_eof_p (buf, SCM_BOOL_F);
>> + return SCM_EOF_VAL;
>> + }
>>
>> - bv = scm_c_make_bytevector (avail);
>> - scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS (bv),
>> - avail, cur, avail);
>> + bv = scm_c_make_bytevector (avail);
>> + scm_port_buffer_take (buf, (scm_t_uint8 *) SCM_BYTEVECTOR_CONTENTS (bv),
>> + avail, cur, avail);
>> + }
>>
>> return bv;
>> }
>
> There are tabs in your code; would you mind doing only spaces?
>
> A port being unbuffered doesn't mean that it has no bytes in its
> buffer. In particular, scm_unget_bytes may put bytes back into the
> buffer. Or, peek-u8 might fill this buffer with one byte.
>
> Also, they port may have buffered write bytes (could be the port has
> write buffering but no read buffering). In that case (pt->rw_random)
> you need to scm_flush().
>
> I suggest taking the buffered bytes from the read buffer, if any. Then
> if the port is unbuffered, make a bytevector and call scm_i_read_bytes;
> otherwise do the scm_fill_input path that's there already.
>
> One more thing, if the port goes EOF, you need to
> scm_port_buffer_set_has_eof_p.
>
> Regards,
>
> Andy
>
>
>
next prev parent reply other threads:[~2018-01-10 16:58 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 [this message]
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
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=CAPjoZoeUvrAtNQLB7HxL0oXTQoK4p0v3cYX2A8f8aVMaG640FQ@mail.gmail.com \
--to=nalaginrut@gmail.com \
--cc=30066@debbugs.gnu.org \
--cc=ludo@gnu.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).