Re: [PATCH 5/5] reflog expire: don't assert the OID when locking refs
- From
Jeff King <peff@peff.net>
- Date
- Mar 14, 2019, 00:44 UTC
- Message-ID
- <20190314004409.GJ31968@sigill.intra.peff.net>
- In-Reply-To
- <20190313235439.30439-6-avarab@gmail.com>
On Thu, Mar 14, 2019 at 12:54:39AM +0100, Ævar Arnfjörð Bjarmason wrote:
> The locking protocol for reflogs involves getting a *.lock file on the > loose ref[1] (even if the actual ref is packed). This isn't needed to > expire the reflog, and needlessly results promotes reference update > contention to hard errors in e.g. "gc".
This first paragraph threw me off. It sounds like you are saying we don't need to take a lock, but we absolutely do. It's just that we don't need to care about the lock having some particular value. Which you do go on to explain, but I think it would be more clear by simply removing this first paragraph.
> If we instead lock the reference without considering what OID we last
> saw it at, we won't encounter user-visible contention to the extent
> that core.filesRefLockTimeout mitigates it. See 4ff0f01cb7 ("refs:
> retry acquiring reference locks for 100ms", 2017-08-21).I think this part is true. I'd love to get a confirmation from Michael Haggerty, who has spent way more time thinking about ref and reflog locking than any mortal should have to. Hopefully he even still remembers some of it. :)
-Peff