Re: A few random I/O proposals

[david carlton <carlton@husc.harvard.edu>]

On Fri, 5 Jun 92 22:28:52 -0400, "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu> said:
>> From: david carlton <carlton@husc.harvard.edu>

>> I don't like this so much.  The ideal way that output should work is
>> for it to be unbuffered - buffering is really just a performance hack
>> adopted out of necessity.  Given that, I think that implementations...

> To which I tried to explain that truly unbuffered serial output is not
> available and not practical on multitasking operating systems.

Yes, I am quite aware of that.  But I'm not proposing that the output
be what you call "truly unbuffered" - it would be nice to have Scheme
be able to run under UNIX and other such operating systems.  I'm
proposing that, in certain circumstances, calls to write-char (and
other output procedures, if they don't call write-char) translate into
calls to the operating system's write call.  (Or something
corresponding to that on machines with more primitive operating
systems.  If you with to think of this in ANSI C terms, a write-char
should in certain circumstances translate into a call to putc()
followed by a call to fflush().)  I think that this is what everbody
else talking on this thread has meant by "unbuffered output".  For
that matter, it's even what you are talking about with your
FORCE-OUTPUT procedure, isn't it?

> The slowdown comes not from the system call overhead (although that
> contributes a second order effect) but from having to wait for
> physical transmission of the character, during which time your
> process can be suspended.

Don't worry - I'm not proposing that processes be forced to wait
around until such time as the character has actually appeared on the
screen, and I have a hard time imagining what good that could possibly
do.  It's good enough for them to have told the operating system to
write it to the screen for them.

>> I am aware that there are other ways to get the desired effect.  I
>> just think that they are a real pain.  I think you need more than just
>> fflush, however - typically I don't care whether or not output is
>> buffered if it is going to a file, for example, so I would only want
>> to flush output if I am not writing to a file.

> But I do need to be able to control when output goes to a file.  There
> might be other readers of the file I am writing or I may need to
> assure that a file (B-trees, for instance) is in a consistent state.

Okay.  So this proposal wouldn't make having a FORCE-OUTPUT useless.
I won't argue with you there.  But having a FORCE-OUTPUT procedure
also wouldn't make this proposal useless, which is what I was saying
above.

david carlton
carlton@husc.harvard.edu

       I know things about TROY DONAHUE that can't even be PRINTED!!