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

[hjstein@bfr.co.il (Harvey J. Stein)]

Craig Brozefsky <craig@onshore.com> writes:

 > Mikael Djurfeldt <mdj@nada.kth.se> writes:
 > 
 > > I think, maybe, that the win in this case (being able to treat files
 > > opened for update in a simpler way than in the POSIX interface) is not
 > > worth the cost involved in its implementation.  I suspect that this
 > > holds even if we try to find a more efficient implementation.
 > 
 > My understanding is that this allows safe read and write to the same
 > port without the user having to flush in between to accommodate for
 > losing STDIO implementations.  If we remove this then we are requiring
 > users to flush if they want their code to be robust on all platforms.
 > Since I do not recall a "flush" procedure to be called on ports in
 > R[45]RS, tho perhaps I just missed it, this would mean not
 > implementing R[45]RS portably in Guile, and not maintaining basic
 > scheme semantics.  Our users should not have to worry about that.
 > 
 > > I plead for dropping this change entirely.
 > 
 > I do too, but only by replacing it with a fix that maintains the
 > present user interface, and performs better, ie, the re-implementation
 > of STDIO buffering that Jim mentioned in his previous post.  In the
 > meantime perhaps a check to see if your on a lame platform or not in
 > the compilation of guile would reduce it's impact on everyone by
 > sparing those with a real STDIO the agony.

You've got this structure of functions for reading & writing to each
port.  Why not stick the fast set in when it's not opened for
read/write & the slow flushing one in when it is?

BTW, can anyone explain to me why one would want to implement
buffering directly instead of using stdio?

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il