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