Re: racy leak sanitizer builds, was Re: [PATCH 0/9] commit-reach: -Wsign-compare follow-ups
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 30, 2024, 13:46 UTC
- Message-ID
- <xmqqy0zx1dx5.fsf@gitster.g>
- In-Reply-To
- <20241229165715.GA3158370@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 16 quoted lines
> One of the reasons I hadn't sent anything is that I was waffling between > two approaches: > > - implement barriers everywhere and just use them. More work, but we'd > have the tool if we wanted to use it later, and all builds behave > the same. > > - make a "maybe_barrier" interface that might be a noop, and let most > platforms compile without them. They are not needed for correct > operation in most cases, but only to work around a sanitizer problem. > And it is not even a problem that comes up frequently; it is a race > that we occasionally see in CI. So enabling it only for our > linux-leaks CI job would be enough to dull the pain. > > And there is no risk of any portability or run-time issues, because > the code is a noop for most builds.
I love when people think before committing to an approach, and after seeing these two cohices, I tend to have slight preference for the latter over the former. The work will not be wasted even if it later turns out that we need a full-blown barrier implementation for other platforms.
Thanks.