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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net