Re: Nonblocking get-bytevector-n bug?

[Marko Rauhamaa <marko@pacujo.net>]

Marko Rauhamaa <marko@pacujo.net>:

> ludo@gnu.org (Ludovic Courtès):
>> That’s because get-bytevector-n{,!} are specified as blocking if
>> necessary until N bytes are read or EOF is reached.
>
> Ok, the Guile manual description leaves it a ambiguous. Even the R6RS
> wording could be graciously bent slightly to support the age-old
> nonblocking semantics. It boils down to what bytes are considered
> "available." I don't think any nonblocking application would mind those
> functions returning immediately with what they managed to read.

In fact, I think Guile definitely *should* bend the R6RS specification
because:

  1. Guile 2.0's get-bytevector-n(!) does not comply with the strict
     R6RS reading anyway. The Guile implementation comes out with a
     system-error (EAGAIN) exception in case a nonblocking port does not
     have any bytes available at the moment. A strict reading would
     entail spinning in a tight loop, which would be silly, of course.

  2. Partial reads throw a system-error (EAGAIN) and lose the already
     read bytes, which makes Guile's get-bytevector-n(!) completely
     unusable for nonblocking ports.

  3. The R6RS wording suggests nonblocking ports were simply overlooked.
     A looser interpretation could be considered compliant.

So, I think get-bytevector-n(!) could become useful if:

  A. If count bytes are available at the moment, follow the spec (no
     change to Guile 2.0.11).

  B. If eof is encountered, follow the spec (no change to Guile 2.0.11).

  C. If no bytes are available at the moment, a system-error (EGAIN)
     exception is thrown (no change to Guile 2.0.11).

  D. If some but fewer than count bytes are available at the moment,
     transfer those bytes and return the number of bytes transferred.

Only item D is new. Wouldn't implementing it have only positives and no
negatives? In fact, without it, how could nonblocking I/O be carried out
effectively?

Note also get-u8 and get-char, which *are* usefully implemented by Guile
for nonblocking ports but are similarly in violation of R6RS (they don't
block until a byte or complete character is available or eof is
reached).


Marko