Path: utzoo!attcan!uunet!mcsun!hp4nl!phigate!ehviea!leo
From: leo@ehviea.ine.philips.nl (Leo de Wit)
Newsgroups: comp.unix.questions
Subject: Re: higher priority to more in "XXXX |more"
Message-ID: <809@ehviea.ine.philips.nl>
Date: 28 Jun 90 07:40:11 GMT
References: <772@teslab.lab.OZ> <1777@necisa.ho.necisa.oz> <807@ehviea.ine.philips.nl> <4879@pegasus.ATT.COM>
Reply-To: leo@ehviea.UUCP (Leo de Wit)
Organization: Philips I&E Eindhoven
Lines: 26

In article <4879@pegasus.ATT.COM> mpl@pegasus.ATT.COM (Michael P. Lindner) writes:
|I've got a proposal that stdio flush output buffers if there is something in
|the buffer for longer than X, where X is some amount of time.  Thus, programs
|that are doing a lot of output get buffering, and line-at-a-time slow going
|programs get their data out into the real world reasonably quickly.  This is
|not hard to implement, either.

This sounds nice, and has the advantage that it doesn't require
adjustment of existing shell scripts (what my proposal - the one with
the environment variables - _does_ need).

However, assuming that you don't mess around with timers and signal
handlers (which is at least tricky in combination with stdio), I can
see two disadvantages:
a) Getting the time implies a system call. This is pretty expensive,
especially when done for every putc(). You could even ask yourself
whether unbuffered I/O (also a system call for each character written)
is that much more expensive.
b) In a lot of cases it just won't work: suppose you just did a
putc('\n',stdout) but the X was not reached yet (the rest of the
characters of the line are also in the buffer). Now suppose it takes a
lot of time before the next character will be putc'ed. Since stdio
doesn't get control, there is no way to get the line flushed reasonably
quickly.

    Leo.