Re: Faster reader (Re: Startup time in guile-1.3 (II))

[Jim Blandy <jimb@red-bean.com>]

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