This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> BTW, can anyone explain to me why one would want to implement > buffering directly instead of using stdio? >From http://www.red-bean.com/guile/notes/ideas.html: Custom buffered I/O Guile has several different kinds of I/O ports. Those that talk to the outside world are implemented on top of the ubiquitous C standard I/O FILE buffered streams. This leads to a few problems: o We have to use fgets for speed, but it's difficult to handle lines containing null characters, given fgets's interface. So we use ftell to find out how much we've read with fgets. But that doesn't work on sockets. So on sockets we fall back to our old, slow routine based on getc. o We have to use unbuffered input sockets, because standard I/O streams only promise you one buffer, so you can't mix read and write operations, to implement a network protocol, say. You have to do an fflush between a write and a read, and an fseek or something equivalent between a read and a write. This is stupid. o There's no way to tell whether there's input immediately available on a buffered stream. You can get the underlying file descriptor and do fcntl magic on that, but that won't tell you whether there are characters waiting in the buffer.