why is fprintf(stderr,) slow?
Chris Torek
chris at umcp-cs.UUCP
Sat Aug 30 22:57:02 AEST 1986
In article <338 at chronon.chronon.UUCP> eric at chronon.UUCP (Eric Black) writes:
>Of course, the reason that [stderr printfs use one system call]
>per character is to make sure that the error output in fact gets
>out.... On BSD systems, at least, you can change this with the
>setlinebuf(3S) call, to make stderr use buffering. ... On non-BSD
>systems you're stuck, as far as I know.
Not stuck: there is still setbuf(3S). A fair fraction of my programs
begin with
char serrbuf[BUFSIZ]; /* buffer for stderr */
main(...)
{
setbuf(stderr, serrbuf);
Further calls to fprintf(stderr) are immediately followed either
by exit(code), which flushes all stdio buffers, or an explicit
fflush(stderr). It is possible to lose error output in some cases;
these I simply put up with, for a simple stack trace tends to
pinpoint them immediately anyway, and even adb prints readable
stack traces (so long as you have symbols!).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP: seismo!umcp-cs!chris
CSNet: chris at umcp-cs ARPA: chris at mimsy.umd.edu
More information about the Comp.unix
mailing list