[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nonblocking get-bytevector-n bug?

From: Chris Vine
Subject: Re: Nonblocking get-bytevector-n bug?
Date: Wed, 9 Dec 2015 00:52:50 +0000

On Wed, 09 Dec 2015 00:02:53 +0200
Marko Rauhamaa <address@hidden> wrote:
> Marko Rauhamaa <address@hidden>:
> > 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]