[API Proposal]: ExecutionContext.Default

[stephentoub]

Background and motivation

Not very commonly but now and then, a developer finds themselves wanting to escape from the current ExecutionContext. For asynchronous work, this can be done via a method like ThreadPool.UnsafeQueueUserWorkItem, which puts work onto the ThreadPool explicitly without flowing the current ExecutionContext, such that the work item will run in what's effectively the default context. But for synchronous work, there isn't a great option. Typical guidance to such a dev, if they're able, is to capture an ExecutionContext at app startup, and then use that captured context with ExecutionContext.Run when they need a default.

API Proposal

namespace System.Threading;

public sealed class ExecutionContext
{
+   public static ExecutionContext Default { get; }
}

(Default actually already exists, but as an internal field rather than as a public property.)

API Usage

// Escape current context
ExecutionContext.Run(ExecutionContext.Default, state => { ... }, state);

Alternative Designs

No response

Risks

No response

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[teo-tsirpanis]

This might be able to replace the new AsyncTaskMethodBuilder().Start() I've been doing, with an ExecutionContext.Run(ExecutionContext.Capture() ?? ExecutionContext.Default, …).

[colejohnson66]

Would it make sense for ExecutionContext.Run to allow null? The function itself throws on null, but then passes right along to RunInternal which does allow null. If I understand the system, null means "no context" - what ExecutionContext.Default would be.

[KalleOlaviNiemitalo]

ExecutionContext.Default would have the advantage that, if you target .NET Standard or .NET Framework, then you get an obvious compile-time error saying it's not available. null would instead lead to a run-time error on .NET Framework.

When targeting .NET Core versions between 3.0 and 10, ExecutionContext.Default has less of an advantage over null because you can get a nullable-reference-type warning.

[stephentoub]

null is likely to be provided by accident, e.g. some ExecutionContext field that hasn't been set yet and that's passed as the argument. ExecutionContext can have significant yet subtle impact on code behaviors; I'd rather the choice to throw away the current context and replace it with the default be as explicit as we can muster.