Re: asynchronous socket library

[Mark H Weaver]

address@hidden writes:
> Reading and writing to a socket seems to lend itself well to custom
> binary ports,

Why do you say that?  For most purposes, Guile's native file ports are
superior, and they seem the natural choice for sockets.

> but then I think you're stuck with an opaque buffer -- you
> can't properly ask the binary port if the next read beyond one byte will
> block or not, since it might have stuff buffered or it might not. I'd
> love to be wrong about that if someone happens to know how to check for
> the amount remaining in a custom binary port's buffer.

'get-bytevector-some' from (rnrs io ports) might do what you need.  If
there's at least one byte available it will not block, but in practice
it reads much more than that (for buffered ports).  Guile 2.0.9 has a
nice fast implementation.  Prior to 2.0.9, it was less so.

In more detail: as of 2.0.9, 'get-bytevector-some' will simply copy the
input buffer managed by Guile into a bytevector and return it.  If
Guile's input buffer is empty, it will try to refill the buffer using
the port type's 'fill_input' method.  For file ports this is
fports.c:fport_fill_input, and for custom binary ports it's
r6rs-ports.c:cbip_fill_input.

Prior to 2.0.9, 'get-bytevector-some' was instead implemented as a loop
that repeatedly called 'char-ready?' and read one byte at a time.  This
would drain more than just Guile's buffer; it would try to drain the
upstream buffers as well.

However, 'char-ready?', and thus the pre-2.0.9 'byte-vector-some',
depend upon the port type providing an 'input_waiting' method.  File
ports provide this, implemented using 'poll' with 0 timeout, see
fports.c:fport_input_waiting.

Unfortunately, custom binary ports do NOT provide an 'input_waiting'
method, so 'char-ready?' always returns true, and I guess this
ultimately means that the pre-2.0.9 'get-bytevector-some' will block
until it reaches EOF.

So again I ask, why use custom binary ports for sockets?

    Regards,
      Mark