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
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
-- 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
Guile Home |
Main Index |