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.
Thanks!
Patrick
Patrick Steinhardt (3):
refs/reftable: introduce "reftable.lockTimeout"
reftable/stack: allow locking of outdated stacks
refs/reftable: reload locked stack when preparing transaction
Documentation/config/reftable.txt | 7 ++++
refs/reftable-backend.c | 9 ++++-
reftable/reftable-stack.h | 13 +++++-
reftable/reftable-writer.h | 8 ++++
reftable/stack.c | 38 ++++++++++++------
t/t0610-reftable-basics.sh | 58 ++++++++++++++++++++++++++
t/unit-tests/t-reftable-stack.c | 67 ++++++++++++++++++++++++++++++-
7 files changed, 181 insertions(+), 19 deletions(-)
--
2.46.0.551.gc5ee8f2d1c.dirty
