Hold a settings scope per flow instead of per thread

[Rafael-SOWNet]

MathS.Settings kept its fourteen values in [ThreadStatic] fields, so a scope stopped at the first await:

using var _ = MathS.Settings.MaxExpansionTermCount.Set(1);
Console.WriteLine(MathS.Settings.MaxExpansionTermCount.Value);   // 1
await Task.Delay(20).ConfigureAwait(false);
Console.WriteLine(MathS.Settings.MaxExpansionTermCount.Value);   // 2000 — the default, silently

The continuation resumes on a pool thread that has never seen the scope. The same mechanism runs the other way, too: a thread going back to the pool still carries whatever scope was left on it, so the next caller to borrow that thread can compute under a precision or codomain it never asked for. Neither surfaces as an error; both change the answer.

The values now live in an AsyncLocal — which is what the cancellation token in MathS.Multithreading already used, so this brings settings in line with a decision the codebase had already made.

Why not just AsyncLocal<Setting<T>> on the field

Because that is wrong. An AsyncLocal flows the reference, and Setting<T> was mutable, so two concurrent tasks would have pushed onto one shared stack and corrupted each other — losing the one property the per-thread field did give.

What has to be per-flow is the value stack itself. So the stack moved inside Setting<T> as an immutable chain behind an AsyncLocal, and the static fields became ordinary singletons. They also had to stop being lazily created: field ??= default on a non-thread-static field races, and a scope opened on the loser of that race would silently vanish.

Scopes are identified by a counter rather than by their frame object. Releasing a scope that is not on top rebuilds the frames above it, and a rebuilt frame is a different object — so keying on the frame left every scope above it impossible to release afterwards. The out-of-order test caught exactly that. Dropping the Guid it replaces is most of why Set() got cheaper.

Behaviour

	was	is
a scope across an await	lost	kept
a scope inside Task.Run started under it	not inherited	inherited
a scope opened in a task, seen by a sibling	no	no
a scope opened in a task, seen after it ends	no	no
a thread reused by the pool	could carry a stale scope	cannot

The second row is the one that can surprise. Work started inside a scope now runs under it — what the code says, and almost always what was meant, but a caller who parallelised inside a scope and relied on the child not seeing it will notice. Every row above is a test in SettingsAcrossAsync.

Cost

Measured over 20 000 000 reads and 2 000 000 scopes, two runs each:

	was	is
read PrecisionErrorZeroRange.Value	7.3–8.0 ns	1.2 ns
read DowncastingEnabled.Value	0.79 ns	0.96 ns
Set() + Dispose()	388–395 ns, 32 B	46 ns, 112 B
a Simplify workload	5.6–5.8 s	5.5–5.6 s, +1.5 % allocated

Reads got faster, not slower: the old getter re-tested a [ThreadStatic] field for null on every access, and that costs more than the async-local lookup replacing it. Opening a scope allocates ~3.5× more, because assigning an AsyncLocal copies the flow's value map — but reads outnumber scope openings by orders of magnitude, and the end-to-end workload is within noise.

Deliberately not changed

The recursion-depth counters and per-thread scratch caches elsewhere (lHopitalDepth, Gruntz.depth, FastExpression.scratch, the constant caches) keep [ThreadStatic]. A recursion depth must not follow a call into a sibling task. RewriteRecording has the same per-thread ambient shape and is left alone here — its documentation already says "on this thread" — but it is worth a look separately.

Verification

• 6069 C# tests pass, 0 failed
• 130 F# wrapper tests pass
• public surface unchanged (PublicApiSurfaceTest green, PublicApi.txt untouched)

Breaking, so it wants the 2.0 window; recorded in BREAKING-CHANGES.md with the migration and the measured before/after.

🤖 Generated with Claude Code