[Top][All Lists]

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

Re: asynchronous socket library

From: mark
Subject: Re: asynchronous socket library
Date: Wed, 17 Jul 2013 09:49:07 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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

reply via email to

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