[Toybox] [PATCH] count.c: Human readable -h option and MAYFORK

[enh]

On Tue, Oct 24, 2023 at 12:31 AM Rob Landley <rob at landley.net> wrote:
>
> On 10/20/23 01:05, Rob Landley wrote:
> >> (though i will accept the argument that "that's a toybox xargs test
> >> bug", but (a) we'll still need to fix that test
> >
> > Any idea off the top of your head which of the 31 tests it was? (I can use the
> > git commit time to go dig back through the web archive and my blog and such, but
> > not right now. I added a TODO note to my tests/xargs.test file to remind me.)
>
> It's the xargs -P tests for parallelism greater than one expecting "y\ny\ny\n"
> output, which is fine with the multiple "echo y" completing in any order, but
> not with the y and \n interleaving from different processes.
>
> This implies that echo's output should be atomic, which linebuf doesn't actually
> guarantee if multiple writes without a newline yet are longer than the internal
> default block buffer size (512 on musl), because the buffer doesn't internally
> realloc to await more input but instead flushes what it can't store. The flag
> just asks it to _try_.
>
> Adding line buffering fixes this _specific_ test, but not necessarily what the
> test is trying to do in general.
>
> https://pubs.opengroup.org/onlinepubs/007904975/utilities/echo.html
>
> Posix of course says nothing about the atomicity of echo's output in parallel
> operation. Nor does the man page.
>
> To make echo's output reliably atomic I'd have to copy the data, for the same
> reason I had to in yes.c. (Because writev() has a 1024 iovec limit, and the
> number of command line entries is unbounded.)
>
> Possibly the test is wrong, and I should change it to call "echo -n" and check
> for 'yyy'. How either way proves they ran in parallel is unclear...

(yeah, if _other_ echo's aren't atomic, it probably doesn't make sense
for you to bend over backwards to make yours atomic.)

> It would be NICE if echo's output was atomic, producing better parallel build
> log output, and maybe telling stdio not to flush early before newline or buffer
> full is good enough? The buffer is _probably_ going to default to >80 character
> lines...
>
> And then the "parallel sleep" test depends on the output of _sed_ being atomic,
> which isn't using stdio for output but instead emit() calls writeall(TT.fdout,
> line, len); which includes the newline when present, so that _is_ atomic.
> (Modulo the usual sources of short writes...) But again, not guaranteed to be by
> anything I can spot...
>
> Rob