Patrick Steinhardt <ps@xxxxxx> writes: > Hi, > > the reftable backend cannot properly handle concurrent writes due to two > reasons: > > - It will bail out immediately when it sees a locked "tables.list" > file. This is being addressed by introducing a configurable locking > timeout, similar to how we have it for both loose and packed refs. > > - It will bail out when it notices that its stack is out-of-date after > having locked the "tables.list" file. This is addressed by reloading > the stack as requested after locking it, which is fine because our > transactional API would verify queued ref updates against their > expected state after the lock was acquired anyway. > > So with this patch series we can now spawn concurrent writers and they > are expected to succeed, which is demonstrated by the test added by the > last patch. > I only had a comment in the first commit. The rest two look good to me. I do wonder if we really need a flag? But that's just a nit. Thanks
Attachment:
signature.asc
Description: PGP signature
