Skip to content

fix: Share one lock when defining scopes - #356

Merged
remimd merged 4 commits into
devfrom
fix/define-scope-lock
Oct 21, 2026
Merged

remimd merged 4 commits into
devfrom
fix/define-scope-lock

Conversation

@remimd

@remimd remimd commented Oct 21, 2026

Copy link
Copy Markdown
Member

No description provided.

Rémi Mandart and others added 3 commits October 21, 2026 14:50
Each define_scope call created its own lock, so checking whether a scope
was already defined and binding it wasn't atomic across threads: two
threads could define the same shared scope, the second overwriting the
first.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every caller now passes an existing lock, so the function no longer
creates one: it returns the given lock when threadsafe, otherwise a null
context. InjectMetadata receives its lock explicitly.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The scope definition lock is renamed to __thread_lock and only protects
the binding of scopes; slot writes use a lock of their own again.
lock_if_threadsafe now creates a lock only when none is given and the
call is threadsafe.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@remimd remimd self-assigned this Oct 21, 2026
No user code runs while the scope locks are held, so they never need to
be reacquired by the same thread. The module lock stays reentrant, since
recipes can resolve dependencies while it is held.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@remimd
remimd merged commit 604b281 into dev Oct 21, 2026
9 checks passed
@remimd
remimd deleted the fix/define-scope-lock branch October 21, 2026 13:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant