Mark H Weaver <m...@netris.org> writes: > m...@markwitmer.com 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
