Hi,
Per Bothner <per_at_bothner.com> writes:
> Fix: remove get-bytevector-some, or clarify that it
> reads "one or more of the available characters". I suggest
> the former.
It seems to me that the issue of `get-bytevector-some' is orthogonal to
that of custom binary input ports (CBIPs).
The semantics of `get-bytevector-some', as I understand it, are similar
to that of read(2) on a blocking file descriptor: it returns at least 1
byte and up to the number of requested bytes; a return value of zero
indicates end-of-file. So here, `get-bytevector-some' should return
either EOF or a non-empty bytevector. I find the report's description
clear enough.
Now, when the input port passed to `get-bytevector-some' is a CBIP, the
specification doesn't require the bytevector returned to be the one that
was passed to the CBIP's `read!' call-back. Therefore,
`get-bytevector-some', `get-bytevector-all' and similar can return a
newly allocated bytevector whose contents are copied from the bytevector
filled in by the `read!' call-back.
I implemented both for Guile and here is how it works: a CBIP has a
fixed-size internal buffer (a bytevector) which it passes to the `read!'
call-back when it's empty (or its contents have already been read).
`get-bytevector-{some,all}' copy data from that internal buffer into a
newly allocated bytevector which they return.
This approach is not zero-copy, but after all, read(2) and fread(3) also
copy data to the user's buffer, so that seems like an acceptable
implementation performance-wise.
Thanks,
Ludovic.
Received on Thu Mar 15 2007 - 07:00:00 UTC