summaryrefslogtreecommitdiff
path: root/contrib/persistent-https
diff options
context:
space:
mode:
authorKarthik Nayak <karthik.188@gmail.com>2026-08-24 11:31:01 +0200
committerJunio C Hamano <gitster@pobox.com>2026-08-24 08:11:18 -0700
commit654567cf1bc756f4f6db5724689008491f8ba628 (patch)
tree2d8ddb4ab34d622e062a67602102a41ce81456ee /contrib/persistent-https
parentcbd35cadfaa9d44463ec7829f15474026aed88ab (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