[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nonblocking get-bytevector-n bug?
From: |
Mark H Weaver |
Subject: |
Re: Nonblocking get-bytevector-n bug? |
Date: |
Tue, 08 Dec 2015 10:39:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Marko Rauhamaa <address@hidden> writes:
> The problem with get-bytevector-some is that there is no limit to how
> many bytes might be returned. In practice, I see that the amount is
> capped at 4096 bytes, but the documentation does not guarantee any
> limit.
While I'm reluctant to guarantee any fixed limit, I can offer this: the
returned bytevector will always be of a manageable size, assuming that
you have not "unread" a huge amount of data, and that you haven't set a
huge buffer size via 'setvbuf'. In the current implementation, the size
is limited by the read buffer size of the port, or the size of the
"putback" buffer.
If 'get-bytevector-some' returns more data than you want, I would
suggest using 'unget-bytevector' to "unread" the unwanted suffix. This
procedure is quite efficient. 'unget-bytevector' was introduced in
Guile 2.0.9.
Would this work for you?
Thanks,
Mark
Re: Nonblocking get-bytevector-n bug?, Amirouche Boubekki, 2015/12/07
Re: Nonblocking get-bytevector-n bug?,
Mark H Weaver <=