On Wed, Mar 24 2021, Jeff King wrote: > On Mon, Mar 22, 2021 at 01:11:49PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> Extend the SPATCH_BATCH_SIZE facility added in >> 960154b9c17 (coccicheck: optionally batch spatch invocations, >> 2019-05-06) and bcb4edf7af7 (coccicheck: make batch size of 0 mean >> "unlimited", 2019-05-08) to allow for both setting >> SPATCH_BATCH_SIZE=N, and also to have a more advanced SPATCH_XARGS >> argument. >> >> The reason to replace the "$$limit" is that now you actually see under >> V=1 what argument your program will get invoked with. >> >> The reason for the "9999" limit is that if you e.g. try to define an >> "$(XARGS)" which is conditionally an empty string or not depending on >> this setting then e.g.: >> >> echo $(FILES) | $(XARGS) $(XARGS_FLAGS) $(SPATCH) >> >> Over multiple lines with "\" will error out. I think just setting it >> to "xargs -n 9999" as a trivial workaround is the best solution here. > > I don't understand this 9999 comment. The original was sometimes setting > $limit to the empty string, and then doing: > > xargs $limit > > How is that any different than setting SPATCH_XARGS to just "xargs" for > the unlimited case? The "over multiple lines" is important. But it seems not anymore. I.e. in an earlier version I had: $(XARGS) \ $(XARGS_FLAGS) \ $(SPATCH) And it would brek if XARGS_FLAGS was empty. So I set it to -n 9999 as a fallback. >> +# For the 'coccicheck' target; SPATCH_XARGS can be used to manually >> +# tweak the xargs invocation. By default we invoke "xargs -n 1", and >> +# "xargs -n 9999" under SPATCH_BATCH_SIZE=0. >> +# >> +# Setting SPATCH_XARGS overrides SPATCH_BATCH_SIZE. To get concurrency >> +# when targeting a single contrib/coccinelle/%.patch use e.g. "-P" if >> +# your xargs(1) supports it: >> +# >> +# make contrib/coccinelle/strbuf.cocci.patch SPATCH_XARGS="xargs -P 8 -n 8" >> +# >> +# Or a combination -jN and "xargs -P": >> +# >> +# make -j4 coccicheck SPATCH_XARGS="xargs -P 2 -n 8" > > As I mentioned in the last round, using "-P" is racy. I'm not sure if > it's something we should be recommending to people. Yes, this would need to use N tempfiles we'd cat together at the end to be POSIX-reliable. In practice I've never seen this sort of thing be unreliable for a case like this. POSIX just guarantees that the output won't be interleaved up to PIPE_BUF, which is typically 4k. We certainly get patches bigger than that from spatch in some cases. But from the OS's perspective emitting this output happens at a glacial pace. So even if it crosses that boundary it's unlikely to be interleaved. Even: perl -wE 'print "a" for 1..1024*1024*100' >1 perl -wE 'print "b" for 1..1024*1024*100' >2 perl -wE 'print "\n" for 1..1024*1024*100' >3 $ du -shc 1 2 3 100M 1 100M 2 100M 3 300M total Which at least on this computer I can't get to not print: $ echo 1 2 3 | xargs -P 3 -n 1 cat|wc -l 104857600 Suggesting that even for output of that size the \n's aren't mixed up. YMMV. Anyway. I think I'll just redact this topic. Maybe I'll change my mind on it, or pick it up some other month/year/whatever. I appreciate everyone's feedback on it, but for something I thought would be a rather trivial bugfix I've sunk way too much time into it. At this point I can't even remember why I was trying to run coccicheck in the first place. There's e.g. still your outstanding feedback on what's really going on with that underlying spatch race I was trying to fix with this --include-headers-for-types workaround. I think digging into that would be interesting for someone, but right now that's not me. I really don't want to spend time on digging into spatch's OCaml guts to figure that & any other outstanding stuff out.