Re: [PATCH 1/5] t5309: run expected-to-fail `index-pack`s with `--threads=1`

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2024, 22:18 UTC
Message-ID: <xmqqfrz496ib.fsf@gitster.g>
In-Reply-To: <588de2e4f16ab090ff477088084e0b81d9615ec5.1704909216.git.me@ttaylorr.com>

Taylor Blau <me@ttaylorr.com> writes:

Show 5 quoted lines

> But that requires us to tweak production code (albeit at a negligible
> cost) in order to appease LSan in this narrow circumstance. Another
> approach is to simply run these expected-to-fail `index-pack`
> invocations with `--threads=1` so that we bypass the above issue
> entirely.

But of course, multi-threaded operation that production folks use will not be tested at all with the alternative.

Show 7 quoted lines

> The downside of that approach is that the test doesn't match our
> production code as well as it did before (where we might have run those
> same `index-pack` invocations with >1 thread, depending on how many CPUs
> the testing machine has). The risk there is that we might miss a
> regression that would leave us in an inconsistent state. But that feels
> rather unlikely in practice, and there are many other tests related to
> `index-pack` in the suite.

As long as "make sure we spawn all of them atmically" has negligible downside, I'd rather take that approach. Buying predictability with minimum cost is quite attractive.

Thanks.