test: use custom wait for watching/helpers.sh

[Alizter]

This allows the fs-memo.t test to succeed on Nix. Before the pid of Dune was being thrown away by a bash bug causing wait to think it was not a child process and rejecting it. We therefore wait instead for all child processes.

[ocaml-benchmarks]

#8201 (40242a5) changes the metrics as follows in comparison to main (a0145b2) when running on fermat (bench/monorepo/bench.Dockerfile):

Benchmark: default

Test: dune monorepo benchmarks

metric_name	Last PR value	Last main value	Delta
build from scratch	1132.841449	1129.820496	0.3%
null build	69.014337	65.869692	4.8%
watch mode: changing file in 'base' library	70.042814	69.897738	0.2%
watch mode: changing file in 'file_path' library	18.019483	18.689723	-3.6%
watch mode: fixing error in file in 'base' library	62.521988	63.562635	-1.6%
watch mode: fixing error in file in 'file_path' library	17.520375	17.633133	-0.6%
watch mode: introducing error in file in 'base' library	8.000441	8.154346	-1.9%
watch mode: introducing error in file in 'file_path' library	2.538723	2.827425	-10.2%

[Leonidas-from-XIV]

Amazing if this will fix the ./helpers.sh: line 25: wait: pid 79252 is not a child of this shell bug I get on every run.

I was implementing something similar (sleep in a loop) but maybe it would be useful to automatically abort after a certain amount of time/iterations have passed to prevent e.g. CI instances from busywaiting.

[Alizter]

@Leonidas-from-XIV The issue with that is it will be very system dependent. Something that takes 1s on my machine may take a lot longer on another. I chose the .1s value on purpose so to not be too slow and not keep the OS busy.

[Leonidas-from-XIV]

@Alizter The problem is that if there is no other cancellation it will busy-wait forever (and unlike wait, take up CPU time) even if there is no chance it will finish. My suggestion is to e.g. add a counter and add to it each iteration and if it reaches, say, 6000 (6000 * 0.1s = 600s = 10min) abort with a failure, that way the test will terminate somewhat reliably if there is an issue.

[Alizter]

@rgrinberg I didn't know that /proc wasn't available outside of linux. I've changed it now to wait on all children processes. This now works on Nix and should be MacOS compatible.

@Leonidas-from-XIV There is already a timeout with this command it seems, so I've changed it back to the regular wait.

[pmwhite]

I just opened #8303 to fix this same issue, but then closed it because this already exists. I don't have a preference either way, but in case it hasn't already been considered, switching from wait to tail fixes the problem as well. I don't know if it is cross-platform enough, though - I'm just running the tests on a Linux machine.

[rgrinberg]

Could you use phil's tail hack instead of this. it seems like it's a more faithful emulation of waiting for $pid than waiting for all jobs.

[rgrinberg]

I don't know if it is cross-platform enough, though - I'm just running the tests on a Linux machine.

It's not. But it's the better workaround on Linux

[Alizter]

@rgrinberg I've used tail instead now. Works on my machine.