On Thu, May 2, 2019 at 11:58 PM Jeff King <peff@xxxxxxxx> wrote: > > I might take a stab at the "wait and try to hold the lock again, doing > > necessary verification after if needed" idea. It sounds like the right > > way to go and we haven't had problems with refs doing the same thing > > (have we?). > > No, but it's a bit easier with refs because the locking is just > atomically checking the lease. I.e., after taking the lock we still say > "we expected the ref to be at oid XYZ, is it still there?". What's the > equivalent for an index operation? That's something for me to find out :) > I think it is more common with the index to take the lock, then while > holding it read it in fresh (possibly dumping old results), manipulate > the result, and then write it out. For callers which make sure to > get a fresh view _after_ taking the lock, they should be OK if taking > the lock is delayed. > > I guess arguably any callers that aren't that careful are already > broken, since it is a race; any delay-and-retry _could_ have happened as > "we were too slow to see the initial lock". I have a feeling that most operations read the index unlocked, manipulate and only lock before writing things out. So yeah it's probably already racy. We could use the trailing SHA-1 to determine if the index has not changed since last time, but then refresh-only updates would be considered valuable while it's not. Full index comparison is way too expensive (at least with giant repos) to even consider. I think I start to see why nobody has done this... -- Duy
