Re: Nonblocking get-bytevector-n bug?

[Chris Vine <chris@cvine.freeserve.co.uk>]

On Wed, 09 Dec 2015 00:02:53 +0200
Marko Rauhamaa <marko@pacujo.net> wrote:
> Marko Rauhamaa <marko@pacujo.net>:
> 
> > It seems to me whoever wrote the spec wasn't thinking of nonblocking
> > ports at all. Are nonblocking ports recognized by RnRS?  
> 
> Took a quick glance at the R6RS spec. It would appear nonblocking
> ports are *not* mentioned or thought of in it.
> 
> Thus, *any* nonblocking behavior would be an extension to R6RS, and
> Guile can do whatever it wishes.

That depends on what you (and other posters) mean.  Non-blocking in the
O_NONBLOCK POSIX sense is not recognised, probably because that kind of
non-blocking does not often make sense in the case of buffered input.
Partial satisfaction of a read request, in the mode of POSIX read() on a
blocking file descriptor, is recognised to the extent that R6RS
get-bytevector-some does something similar to read() for R6RS ports.

If you are using select then it is the second of those which is
important - you know something is available, but not how much.  What is
lacking for this is something like a get-bytevector-some! procedure.

If you are using guile's POSIX wrapper of fcntl on a scheme port I am
not sure what it does.  It would be consisent with POSIX's fread() if
it threw a EAGAIN exception if nothing is available.  As you say,
because such ports are not recognised by RnRS they can do what they
want.

Chris