diff options
| author | Karthik Nayak <karthik.188@gmail.com> | 2026-08-24 11:31:01 +0200 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2026-08-24 08:11:18 -0700 |
| commit | 654567cf1bc756f4f6db5724689008491f8ba628 (patch) | |
| tree | 2d8ddb4ab34d622e062a67602102a41ce81456ee /contrib/persistent-https | |
| parent | cbd35cadfaa9d44463ec7829f15474026aed88ab (diff) | |
reftable/stack: move list lock to `struct reftable_stack`
The struct `reftable_addition` is used to modify a given stack, as such,
it also includes a `struct reftable_flock` used to obtain the lock to
the list file. While the scope of the field lies within this struct, it
doesn't allow for optimizations to be made on `struct reftable_stack`
itself.
Move the field to `struct reftable_stack`, allowing us to make a simple
optimization around avoiding a stack reload when we have already
obtained a lock. While this is currently possible in the write path, the
write path also contains multiple branches to reads which only work
on top of `struct reftable_stack`, and we would miss the optimization in
such paths.
Since the lock is now shared across all additions on the same stack, a
second `reftable_addition` that fails to acquire the already held lock
would still call `reftable_addition_close()`, which will release the
`stack->list_lock` which is still held by the first addition. To avoid
this, add a new bit field `locked` to `reftable_addition` that tracks
whether a particular addition is the one holding the lock, and only
release it in that case. Add a unit test to validate this behavior.
While here, remove an unused header file from 'reftable/stack.h'.
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions
