[Toybox] [PATCH] xputs: Do flush

[Rob Landley]

On 5/20/24 08:32, Yi-Yo Chiang wrote:
> Thanks! Adding TOYFLAG_NOBUF worked.
> 
> I feel the same way about "manual flushing of the output buffer is a terrible
> interface". I asked myself the question "Why am I manually flushing so much?
> There must be a better way..." multiple times when I wrote the other patch that
> does s/xprintf/dprintf/, s/xputs/xputsn/

It's an annoying design quandry.

>     > Your other patch changes a bunch of xprintf() to dprintf() which is even
>     _more_
>     > fun because dprintf() writes directly to the file descriptor (bypassing the
>     > buffer in the libc global FILE * instance "stdio"), which means in the absence
>     > of manual flushing the dprintf() data will go out first and then the stdio
>     data
>     > will go out sometime later, in the wrong order. Mixing the two output formats
>     > tends to invert the order that way, unless you disable output buffering.
> 
> Which is the reason I replaced those all with the "flush" functions (xputsn) or
> direct fd-write functions (dprintf), so that their order won't shuffle.
> Anyway the problem is moot now that we have TOYFLAG_NOBUF.

Eh, not moot. Shifted. Currently there's one command using TOYFLAG_NOBUF, and a
lot of recent buffering fixes:

ea119151ccc5
59b041d14aec
afeed2d46a9a
a57e42a386b0
ca6bde9e1c43

I should probably audit all the commands and figure out which buffering type to
use for each. (grep currently finds manual fflush() in hexedit, login, watch,
and ps).

But not today...

> > But that hasn't been popular, and it's a pain to implement in userspace (because
> > we don't have access to mulitple cheap timers like the kernel does, we need to
> > take a signal and there's both a limited number of signals).
> 
> do you run on anything that doesn't have real-time signals? i was
> going to say that -- since toybox is a closed world -- you could just
> use SIGUSR2, but i see that dhcp is already using that! but if you can
> assume real-time signals, there are plenty of them...

Within toybox I could probably come up with something, true. Although fflush()
locking is still a bit problematic if I'm not depending on thread
infrastructure. (Either I don't use FILE * and do it myself, or I require libc
to be thread aware.)

Rob