[Toybox] Weird stdout buffering effects

Ray Gardner raygard at gmail.com
Mon Oct 23 16:13:31 PDT 2023


Rob, thanks for the info, I learned some stuff about pipes from it.

I also looked up setvbuf(), and the standard says it may not be used after
a previous successful call to setvbuf(). That makes my tests below kinda
moot.

But still, using _IOLBF and then _IOFBF seems to work with glibc and musl
to get fast output.

So, to get fast output from any toy, I think there should be an option to
do no call to setvbuf() at all. What is the reason for defaulting to no
buffering? If it's a must, maybe need TOYFLAG_DEFAULTBUF or something.

I ran some more tests, outside of toybox, with setting stdout mode once,
or twice in sequence, before writing to stdout. These tests are all with
redirection to a file.

Using printf(); real and sys are glibc, user was negligible. xmusl is musl
with xprintf().

 _IONBF  _IOLBF  _IOFBF   real    sys    musl   xmusl
-------  ------  ------   ----   ----    ----    ----
    Y                    26.2     5.3    25.8    13.9
            Y            13.1     2.6    13.2    13.1
    Y               Y    25.5     5.2    26.0    13.9
    Y       Y            39.4     8.0    26.2    13.0
            Y       Y     0.1     0.0     0.2     0.2
*** Y  (with xprintf)    13.4     2.8    25.8    13.9

BTW, a few days ago you wrote:
> Also... adding LINEBUF when the calls are xprintf() and xputc()... those
> are explicitly supposed to flush. Flushing and checking errors are what
> those DO.

But xprintf() does not flush.

About the terminal: yes, it's gnome. But I'm not sending anything to it.
These things are all command-line piping and redirection, which I thought
was all in the shell, so how does the terminal figure into it?

BTW, I enjoyed the maddog anecdote. And IndyCar switched from methanol to
an ethanol blend in 2007 for safety.


More information about the Toybox mailing list