API Proposal: ExecutionContext.Run<TContext> overloads

[davidfowl]

Today to run code on a specific ExecutionContext, there's a non-generic Run method that takes a ContextCallback and object state. We should add a generic overload to boxing can be avoided (for e.g. when passing a ValueTuple):

namespace System.Threading
{
    public sealed class ExecutionContext
    {
        // New
        public static void Run<TState>(ExecutionContext context, ContextCallback<TState> callback, ref TState state);

        // Existing
        public static void Run(ExecutionContext executionContext, ContextCallback callback, object? state);
        ...
    }

    // New (it exists but as internal)
    public delegate void ContextCallback<TState>(ref TState state);

    // Existing
    public delegate void ContextCallback(object? state);
}

[stephentoub]

We effectively already have this internally (I added it to support ManualResetValueTaskSourceCore). But it also highlights that the state should be passed as ref, not in, to support mutating such state without allocation.

[stephentoub]

Also, I think the generic parameter should be TState rather than TContext, since it could otherwise imply it's somehow the type of the ExecutionContext.

And we should consider whether we actually want a new generic ContextCallback delegate, or instead add a more general purpose Action (this is just about the delegate name and namespace).

[davidfowl]

Made those changes. I'd also like a Func<TState, TResult> overload so I can do this:

protected override Task ProcessRequestAsync<TContext>(IHttpApplication<TContext> application, TContext context)
{
    var s = (application, context);
    return ExecutionContext.Run(_executionContext, state => 
    {
        return state.Appliation.ProcessRequestAsync(state.Context);
    }, 
    ref s);
}

[stephentoub]

I'd prefer to keep the number of additional overloads here smaller, to avoid the bloat that comes from introducing additional generic methods and the necessary plumbing internally (ExecutionContext.Run is not a small method), etc, and just add the single void-returning overload. This is an advanced class that very little code needs to use directly, and it's ok to have more advanced use cases be a little more cumbersome in exchange for reduced bloat. Your desired ProcessRequestAsync could be done almost as easily with the void-returning overload:

protected override Task ProcessRequestAsync<TContext>(IHttpApplication<TContext> application, TContext context)
{
    var s = (application, context, (Task)null);
    ExecutionContext.Run(_executionContext, (ref state) => // the ref state would actually need the declaring tuple type here, but that's the case in your sample code as well ;)
    {
        state.Item3 = state.application.ProcessRequestAsync(state.context);
    }, ref s);
    return s.Item3;
}

[davidfowl]

What's the harm in adding another overload? Is it just because it's an advanced API?

This is an advanced class that very little code needs to use directly, and it's ok to have more advanced use cases be a little more cumbersome in exchange for reduced bloat. Your desired ProcessRequestAsync could be done almost as easily with the void-returning overload:

After discovering quirks with async locals last night, more code needs to call this than I originally thought does need to call it (or use an async state machine).

Also,I think we need ContextCallback to allow passing the state by ref

[stephentoub]

What's the harm in adding another overload? Is it just because it's an advanced API?

A gigantic and complicated method in Corelib duplicated again (https://github.com/dotnet/coreclr/blob/09b000f7e734e2744892f482242fe6bb66c60d59/src/System.Private.CoreLib/shared/System/Threading/ExecutionContext.cs#L204-L271), an additional public delegate type, additional public API surface area for niche functionality that can be accomplished without that surface area, etc.

[stephentoub]

Also,I think we need ContextCallback to allow passing the state by ref

That's why I wrote "add a more general purpose Action (this is just about the delegate name and namespace)", i.e.

namespace System
{
    public delegate void Action<T>(ref T arg);
}

[davidfowl]

A gigantic and complicated method in Corelib duplicated again (https://github.com/dotnet/coreclr/blob/09b000f7e734e2744892f482242fe6bb66c60d59/src/System.Private.CoreLib/shared/System/Threading/ExecutionContext.cs#L204-L271), an additional public delegate type, additional public API surface area for niche functionality that can be accomplished without that surface area, etc.

Fair enough, it just goes to show that APIs that take callbacks usually need to account for all the ways code can be called (that includes return values).

That's why I wrote "add a more general purpose Action (this is just about the delegate name and namespace)", i.e.

ActionRef? Does it need to be general purpose?

[stephentoub]

ActionRef? Does it need to be general purpose?

Not sure. Just something to consider.

[benaadams]

Often I want to run with the current context; but prevent spilling (which I think @davidfowl is also trying to do).

At the moment you need to do

ExecutionContext.Run(ExecutionContext.Capture(), ...

Would be good if you could avoid the capture and the EC Run could just use the current one; rather than converting it from its internal state; then passing it back in, when it converts it back to its internal state.

[benaadams]

public sealed class ExecutionContext
{
    public static void Run(ContextCallback callback, object? state);
    public static void Run<TState>(ContextCallback<TState> callback, ref TState state);
    ...
}

Which could then be utilised internally; if desired:

internal static class AsyncMethodBuilderCore
{
    public static void Start<TStateMachine>(ContextCallback<TStateMachine> callback, ref TStateMachine stateMachine) where TStateMachine : IAsyncStateMachine
    {
        if (stateMachine == null) // TStateMachines are generally non-nullable value types, so this check will be elided
        {
            ThrowHelper.ThrowArgumentNullException(ExceptionArgument.stateMachine);
        }
        
        ExecutionContext.Run(callback, ref stateMachine);
    }
} 

[stephentoub]

Would be good if you could avoid the capture and the EC Run could just use the current one; rather than converting it from its internal state; then passing it back in, when it converts it back to its internal state.

What overhead are you talking about that could be avoided, and you have measurements to show that it actually matters when using in any of these consuming scenarios?

[benaadams]

What overhead are you talking about that could be avoided,

null getting changed into the default context for capture; then back to null internal to Run

And because of flow suppression you need to check if the EC is null before using Run... but

Flow suppressed gets changed into null for capture, then... well... then, you are kinda stuffed as Run will throw, so you need to have a stashed EC to run on.

So it gets complicated; because you can't set EC directly (which is fine); but an api to say run this on the current context, then throw away its changes when you return would be good.

Much like AsyncMethodBuilderCore.Start<TStateMachine> is doing.

[GrabYourPitchforks]

API review - approved.

Please match parameter names for the new overloads to parameter names for the existing overloads.