[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