[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few random I/O proposals



On Sun, 31 May 92 22:11:01 -0400, "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu> said:
>> Date: Sat, 30 May 92 12:31:05 -0400
>> From: david carlton <carlton@husc.harvard.edu>

>> With terminals, there is essentially no loss from not buffering
>> output, since programs can generate unbuffered output faster than
>> humans or terminals can handle.

> You have this backwards.  There would be a very large performance
> impact because you would be requiring your process to be running to
> send each character.  Each character write would cause your process to
> be swapped out if there were another process to run.  This would limit
> you to about 60 cps on many systems.  This is below the 100 cps of a
> 9600 buad line (which can easily be acheived with buffering).

I don't understand this paragraph.  It seems to me that the main extra
overhead from unbuffered output is that you would have to do a system
call on each character that you output, and system calls are
relatively slow.  But do they normally make it more likely that your
process be swapped out as well?  (More likely compared to if you were
taking the same amount of time as you did with unbuffered output, just
not doing any system calls.)  I just ran a simple test case of a pair
of programs one of which looped and did nothing (to make sure that
there was always another process waiting to run) and the other of
which wrote characters to my xterm, flushing after each character, and
the latter program wrote about a (24x80) screenful of text a second,
which is plenty fast enough for screen output for me and a lot faster
than the figures that you come up with.  But I don't claim to know
much about the intricacies of UNIX (or other operating systems')
process management, so maybe I am missing something.

>> And there are definite gains - I don't want to have to wait until a
>> Scheme program has generated 8k of text before seeing any of it.
>> Similarly, if a Scheme system is started up interactively, I don't
>> think that output to the inital (current-output-port) should be
>> buffered.  Implementors may also decide that output to pipes shouldn't
>> be buffered.

> You don't have to give up buffering in order to see output before the
> buffer is full.  Posix fflush will do it.  Newline could additionally
> be specified to fflush (at least to current-output-port).

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.  And so forth and so
on.  I would far prefer to have the Scheme implementation to do a good
guess for me as to whether or not I care about seeing the output
immediately, leaning towards the "I care" side, and avoid me all of
that trouble.

david carlton
carlton@husc.harvard.edu

       It's NO USE..  I've gone to ``CLUB MED''!!