stdout buffering question

[John Woods]

>with appropriate arguments. The snag I have run into is that it appears
>that when a process is execed the operating system does you a favor and
>make stdout buffered. The result is that nothing is written into the pipe
>for stdout until the child flushes stdout or the child exits. If in the child
>the buffer size is set to 0 using setbuf then every thing works fine. However
>one constraint for what I am trying to do is that no changes (like adding the
>setbuf call) can be made to the child process. Calling setbuf after I fork
>but before the exec doesn't seem to work. The decision to have buffered
>output seems to be done at exec time.

I'm sure this will get beaten to death, but here goes:

The operating system has not soiled its hands with this buffering decision.
The standard IO library did.  Normally, all standard IO streams are buffered
save those going to terminals.  When you did the exec, you loaded a whole
new program that got to discover for itself that it's output stream was not
connected to a terminal, and therefore to save you some processor time, it
elected to buffer standard output.  Alas, in the case of pipes, this behavior
is sometimes not what one wants (sometimes it is).

What you must do is add setbuf to the child process.  Since you can't do
this, you may be stuck (you probably don't want to adb the binary to add
the unbuffered flag to the stdout structure, either...).

Hope this helps.

-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc at MIT-XX.ARPA

You can't spell "vile" without "vi".