Btukfyl

Hi All,

I plan to develop a custom awaiter quite similar to one presented in this brilliant article:

http://blogs.msdn.com/b/lucian/archive/2012/11/24/how-to-hibernate-async-methods-how-to-serialize-task.aspx

In short, it allows serializing the state of an async method, to be deserialized and resumed at a later time.

My concern is that the implementation (for .NET 4.5) is based on a hack of accessing a private field m_stateMachine of struct AsyncMethodBuilderCore, which is an internal type in mscorlib.

I edited the question following @Peter's comment:

I wonder if anyone who installed .NET 4.6 or .NET Core (ASP.NET 5) previews and investigated async/await in those versions, saw any change in how the compiler generates the state machine behind async/await, compared to .NET 4.5?

Some background

I am exploring possibility of authoring long-running workflows (similar to those provided by Windows Workflow Foundation) using C# async/await syntax. Which means that in my case, async/await must be backed by persistence and tracking mechanisms. Then the code of a workflow would look like this:

public class ProcessingWorkflowOfForm12345C : AbstractWorkflow<Form12345C>

{

    private readonly ExternalServices _services;



    public ProcessingWorkflowOfForm12345C(ExternalServices services)

    {

        _services = services;

    }



    public override async void Run(Form12345C form)

    {

        while ( form.ExtraDocumentsRequired )

        {

            var extraDocuments = await _services.RequestExtraDocuments(

                form.GetRequiredExtraDocuments()); // can take weeks

            form.AddExtraDocuments(extraDocuments);

        }



        var approvalResult = _services.AutoApprove(form);



        while ( true )

        {

            switch ( approvalResult )

            {

                case ApprovalResult.Approved:

                    form.SetApproved();

                    return;

                case ApprovalResult.Rejected:

                    form.SetRejected();

                    return;

                case ApprovalResult.Manual:

                    approvalResult = 

                        await _services.RequestManualApproval(form); // can take days

                    break; 

            }

        }

    }

}

The state machine generator has not changed, it's still exactly the same. The only thing that changed starting with .NET Core 2.1 is the new type AsyncStateMachineBox replaced MoveNextRunner.

You can find source code that accesses fields of a state machine for serialization here:
https://github.com/Dasync/Dasync/tree/master/Engine/AsyncStateMachine

P.S. there are obvious benefits of using compiler-generated state machines for distributed computing. As of today, this can be viewed as a hack, perhaps tomorrow it comes as a built-in language support.
Conquest of Distributed Systems (part 4) — The Now and the Vision