On Tue, Oct 24, 2023 at 12:31 AM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
