Justin Erenkrantz wrote:
> I will veto any patches that attempt to add a guarantee of
> line-buffering but do not so consistently across the board. I refuse
> to see us take half-hearted approaches - we're not CVS.
>
> Enough people have said that flushing is a good idea that I'm sure
> lots of people are willing to write the patch. I'd be willing to
> review them. I do caution that a complete solution is going to be
> larger than three one-liners. -- justin
Actually, if it's preferable to do it globally, the solution is a *single*
one-liner :-), either:
setlinebuf(stdout);
or
setvbuf(stdout, (char *)NULL, _IOLBF, 0);
This explicitly requests line-buffered stdout, rather than just accepting
whatever the OS chose to give us (typically line-buffered for a pty and
block-buffered for anything else, but not actually guaranteed AFAIK). Since
this changes the actual buffering policy in stdio, it should make the case
where stdout is redirected exactly the same as the current case where it
isn't.
I've usually used setlinebuf (which is 4.2BSD), since it's easier to
remember, but I'm not sure about the portability of it (this issue has
never before come up in an app where I cared about the portability).
setvbuf is C89, which should be portable enough. Either call is documented
as something which must be done "after opening the stream, and before any
other operations have been performed on it", so this would have to be done
early in the svn commandline client's initialization; it doesn't appear to
inherit across exec (at least on linux), so it's apparently not something
that a caller can force.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 9 13:14:59 2006