How do ScopedValue bindings interact with structured concurrency and forked subtasks?

## Two features that are designed together **Structured concurrency** (JEP-developed alongside virtual threads, finalized Java 25) treats a group of concurrent subtasks as a single unit of work. The pattern: ```java try (var scope = StructuredTaskScope.open()) { // shape varies by Java version Subtask<A> a = scope.fork(() -> fetchA()); Subtask<B> b = scope.fork(() -> fetchB()); scope.join(); // wait for both use(a.get(), b.get()); } // scope closes: all subtasks done ``` Key property: subtasks are **confined** to the scope's dynamic extent. `fork` starts each on its own virtual thread; `join` waits for them; the `try`-with-resources close guarantees none outlive the block. Errors and cancellation propagate as a unit. (Exact API names have shifted across preview rounds; the model is stable.) **ScopedValue** binds immutable context for a dynamic extent. Put them together and you get implicit context that flows correctly across a *tree* of threads. ## Inheritance: how subtasks see parent bindings When you bind a scoped value and then fork subtasks **within** that binding's extent, each subtask runs inside the parent's dynamic scope. Therefore: ```java static final ScopedValue<String> REQUEST_ID = ScopedValue.newInstance(); ScopedValue.where(REQUEST_ID, "req-42").run(() -> { try (var scope = StructuredTaskScope.open()) { scope.fork(() -> { // inherited automatically — no parameter passing log(REQUEST_ID.get()); // "req-42" return doWork(); }); scope.fork(() -> { log(REQUEST_ID.get()); return doMore(); }); // also "req-42" scope.join(); } }); ``` Both forked subtasks read `REQUEST_ID` even though nobody passed it in. This is the **inheritance** guarantee: subtasks of a structured scope inherit the scoped-value bindings in effect when they were forked. ## Shared by reference, not copied Because a ScopedValue is **immutable**, the runtime can let every subtask reference the *same* binding rather than copying it. With a large fan-out (say forking thousands of subtasks), that's a major efficiency win and the whole reason this is viable at virtual-thread scale. Contrast **InheritableThreadLocal**, which copies each value into every child thread at creation — O(children × values) work and memory, plus no automatic teardown. ## One-directional and well-scoped Inheritance flows **downward and outward-in**: a subtask sees what the parent bound. The reverse is not true — if a subtask opens its own `where(KEY, x)` binding internally, that binding is local to that subtask's extent and is gone when the subtask finishes; it does not leak to siblings or back to the parent. This matches the immutability/stack-discipline model: context flows down the tree, never up. ## Why this combination matters - **Leak-free propagation:** the binding's lifetime is exactly the parent scope; when the structured scope closes, everything unwinds. No `remove()`, no stale context on reused carrier threads. - **Correctness across cancellation:** if the structured scope cancels/short-circuits (e.g., first failure), subtasks are interrupted and the bindings unwind with them — no orphaned context. - **Replaces InheritableThreadLocal cleanly:** same "children see parent context" capability, but immutable, shared-by-reference, lifetime-bounded, and cheap. ## Caveats - A subtask only inherits bindings that were in effect **at fork time**. Binding a value *after* forking does not retroactively reach already-forked subtasks (and structurally you bind before forking). - If you fork a *bare* virtual thread outside any structured scope, you don't get this inheritance guarantee — the point is the structured containment that ties subtask lifetime to the binding's extent.