[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few random I/O proposals
On Fri, 5 Jun 92 22:28:52 -0400, "Aubrey Jaffer" <firstname.lastname@example.org> said:
>> From: david carlton <email@example.com>
>> 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
I know things about TROY DONAHUE that can't even be PRINTED!!