AsyncMethodBuilder Start How to Capture Execution Context?

[timcassell]

In the internal AsyncMethodBuilderCore, the Start function captures the current synchronization and execution contexts, then restores them after calling stateMachine.MoveNext();

Thread currentThread = Thread.CurrentThread;

ExecutionContext? previousExecutionCtx = currentThread._executionContext;
SynchronizationContext? previousSyncCtx = currentThread._synchronizationContext;

try
{
    stateMachine.MoveNext();
}
finally
{
    if (previousSyncCtx != currentThread._synchronizationContext)
    {
        currentThread._synchronizationContext = previousSyncCtx;
    }

    ExecutionContext? currentExecutionCtx = currentThread._executionContext;
    if (previousExecutionCtx != currentExecutionCtx)
    {
        ExecutionContext.RestoreChangedContextToThread(currentThread, previousExecutionCtx, currentExecutionCtx);
    }
}

I'm looking to implement this logic in my own custom AsyncMethodBuilder, but the code there is using internals that I don't have access to without reflection.

How can I properly implement that?

[stephentoub]

Use ExecutionContext.Run, or use the Start method of a temporary AsyncTaskMethodBuilder, ala https://github.com/dotnet/corefx/blob/a0e326571517f03e8d6ccaf88b250b9b45961fff/src/Common/src/CoreLib/System/Runtime/CompilerServices/AsyncValueTaskMethodBuilder.cs#L42

[timcassell]

Oh, so it's as simple as this?

new System.Runtime.CompilerServices.AsyncTaskMethodBuilder().Start(ref stateMachine);

Sweet!

[timcassell]

So now I'm curious, why does that code use 2 paths for Standard vs Core?

#if netstandard
            _methodBuilder.Start(ref stateMachine);
#else
            AsyncMethodBuilderCore.Start(ref stateMachine);
#endif

Is the Core version more efficient? Is it fine for me to use the Standard version either way?

[stephentoub]

Is it fine for me to use the Standard version either way?

Yes.

Is the Core version more efficient?

Ever so slightly. If you look at the implementation of AsyncTaskMethodBuilder.Start, it just calls AsyncMethodBuilderCore.Start. Since the core implementation doesn't need the _methodBuilder for other reasons, it just calls AsyncMethodBuilderCore.Start directly.