Guile Mailing List Archive

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

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

> > It's completely insane to do that much work for every character
> > being read in the innermost loop of the reader.
> What about letting the reader read one full line (or more) at a time
> into an internal buffer and then use a simple character pointer to
> read the individual characters?

If you're going to do that, you should do so in a way that benefits
all of Guile.  Basically, you're talking about re-implementing stdio's
buffering.  I think that's a great idea --- in fact, it's on the list
of projects looking for volunteers that I just posted.

> (BTW, what was that pre_read and pre_write change about?  I saw that
>  pre_read seems to flush output when switching to read.  But isn't
>  this made automatically by STDIO?  I think reading is one of the
>  conditions when output is flushed.  What else did this change
>  handle?)

The comment above the code you found reads:

/* Port direction --- handling el cheapo stdio implementations.

   Guile says that when you've got a port that's both readable and
   writable, like a socket, why then, by gum, you can read from it and
   write to it!  However, most standard I/O implementations make
   cheezy caveats like this:

	When a file is opened for update, both input and output  may
	be done on the resulting stream.  However, output may not be
	directly followed by input without an intervening  fflush(),
	fseek(),  fsetpos(),  or  rewind(),  and  input  may  not be
	directly followed by output without an intervening  fseek(),
	fsetpos(),   or   rewind(),   or  an  input  operation  that
	encounters end-of-file.
		   -- the Solaris fdopen(3S) man page

   I think this behavior is permitted by the ANSI C standard.

   So we made the implementation more complex, so what the user sees
   remains simple.  When we have a Guile port based on a stdio stream
   (this source file's specialty), we keep track of whether it was
   last written to, read from, or whether it is in a safe state for
   both operations.  Each port operation function just checks the
   state of the port before each operation, and does the required
   magic if necessary.

   We use two bits in the CAR of the port, FPORT_READ_SAFE and
   FPORT_WRITE_SAFE, to indicate what operations the underlying stdio
   stream could correctly perform next.  You're not allowed to clear
   them both at the same time, but both can be set --- for example, if
   the stream has just been opened, or flushed, or had its position

   It's possible for a port to have neither bit set, if we receive a
   FILE * pointer in an unknown state; this code should handle that
   gracefully.  */

Guile Home | Main Index | Thread Index