Re: asynchronous socket library

[mark]

Mark H Weaver <address@hidden> writes:

> 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.
>

I over-generalized. In my application, I'm using the X protocol, which
is a binary one. I've been so involved with that I forgot that much of
the time you want to read/write character data from a socket.

> '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.

In order to know if the port has at least one byte ready, you need to be
able to call 'char-ready?', don't you? And as you mentioned, that
doesn't work on custom binary ports. I'm still exploring this part of
Guile so I might not have the details right.

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

Thanks for the detailed explanation; I think I'll move away from
them. Were they added just to meet the r6rs spec? Are there any good
uses for custom binary ports that you're aware of?

-- 
Mark Witmer