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

[Rob Landley]

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...

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