mpl@pegasus.ATT.COM (Michael P. Lindner) (06/27/90)
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. Mike Lindner attmail!mplindner
leo@ehviea.ine.philips.nl (Leo de Wit) (06/28/90)
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.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/28/90)
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.
How weird. Can you do this without planting a signal handler and setting
up an alarm? I'd hate to see the standard library start using alarms.
This behavior also might be considered contrary to that specified in the
C standard.mpl@pegasus.ATT.COM (Michael P. Lindner) (06/30/90)
In article <809@ehviea.ine.philips.nl> leo@ehviea.UUCP (Leo de Wit) writes: >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 deleted >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: deleted Ah, but I DO mess around with timers and signal handlers. The overhead is about 2 instructions per putc/fwrite/printf/whatever, with an extra function (and possibly a system call every X seconds). This may or may not be acceptable, but I think it'll work. I haven't actually written the code and tried it, but yesterday Andrew Koenig wrote me and pointed out all the problems I would encounter (and some of the solutions to them) and I am convinced after thinking some more that it could be done. Whether or not it would be a win or a loss is left as an exercise to the reader. I don't want to waste net time on this, but if someone is really interested, they're welcome to try implementing it and reporting to the net. My thanks to Andrew Koenig, who was able to debug my ideas in his head (I guess that's what you get from writing such excellent books as "C Traps and Pitfalls"). As to whether or not the proposal would be conformant to ANSI or anybody, I don't know, but I do think it's useful in quite a few situations. Mike Lindner