On Tue 26 Feb 2013 20:59, Andy Wingo <wi...@pobox.com> writes:
> On Tue 26 Feb 2013 20:50, Mark H Weaver <m...@netris.org> writes:
>
>> Andy Wingo <wi...@pobox.com> writes:
>>> Are you proposing that `char-ready?' do a nonblocking read if
>>> the buffer is empty? That could work.
>>
>> Yes. I suspect that something along these lines is already implemented,
>> because I don't see how 'u8-ready?' could work properly without it.
>
> It does a poll with a timeout of 0.
In the end I added this to the manual:
Note that @code{char-ready?} only works reliably for terminals and
sockets with one-byte encodings. Under the hood it will return
@code{#t} if the port has any input buffered, or if the file descriptor
that backs the port polls as readable, indicating that Guile can fetch
more bytes from the kernel. However being able to fetch one byte
doesn't mean that a full character is available; @xref{Encoding}. Also,
on many systems it's possible for a file descriptor to poll as readable,
but then block when it comes time to read bytes. Note also that on
Linux kernels, all file ports backed by files always poll as readable.
For non-file ports, this procedure always returns @code{#t}, except for
soft ports, which have a @code{char-ready?} handler. @xref{Soft Ports}.
In short, this is a legacy procedure whose semantics are hard to
provide. However it is a useful check to see if any input is buffered.
@xref{Non-Blocking I/O}.
We could try a non-blocking read but at that point we should just
provide a non-blocking read-char, and allow users to unread-char. That
would be a different bug :)
Andy
