Repository navigation
Decorate fork bodies with Scope.FORK_DECORATOR - #394
Open
pawelsadlo wants to merge 3 commits into
Open
pawelsadlo wants to merge 3 commits into
pawelsadlo wants to merge 3 commits into
Conversation
Forks are started by the thread which runs `supervised`, not by the one which
calls `fork`: `fork` sends a command down the supervisor channel, and the
thread is created later, by the scope's loop. So values which are propagated
when a thread is created - `ScopedValue`s, or a context held in a thread local
- are inherited from the thread which opened the scope, and not from the one
which started the fork.
A `ScopedValue` bound inside a scope body is therefore invisible to the forks
started under it:
supervised(scope -> ScopedValue.where(V, "x").call(() ->
scope.fork(() -> V.isBound()).join())); // false
`Scope.FORK_DECORATOR` takes a `ForkDecorator`, applied to the fork's body on
the thread which calls `fork`, where that thread's state is still available.
The decorator can capture it, and restore it around the body.
It is generic - it only maps a `Callable` to a `Callable` - so it can carry a
`ScopedValue`, a thread-local context, an MDC, or anything else inherited at
thread creation. Applied in `fork`, `forkUser`, `forkUnsupervised` and
`forkCancellable`, so flow operators which fork internally are covered too.
When the scoped value is unbound, `fork` is unchanged.
Co-authored-by: Claude-Opus-4.8 via Claude-Code <noreply@anthropic.com>
Co-authored-by: Claude-Opus-4.8 via Claude-Code <noreply@anthropic.com>
Co-authored-by: Claude-Opus-4.8 via Claude-Code <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Needed for #395 as a tool to propagate opentelemetry context to forks
This is OpenTelemetry agnostic approach that enables propagation of open telemetry context.
Scope gets a new ScopeLocal field "Fork_decorator" which can be used to decorate fork creation logic.
decoration is invoked when fork() method is called (not when forked thread runs it)
Why its needed for OpenTelemetry context propagation:
Threads are created inside supervised block by thread which runs
supervised, not by the one which callsfork.Therefore propagation approach used in ox, via (virtual) thread factory doesn't work, because all threads (and their threadLocals) are children of one thread, even though they are syntactically nested.
#395 introduces
which can be bound to scopelocal value of Fork_decorator to propagate open telemetry context properly.
ScopeLocal storage of
Decoratorenables this feature with minimal api change