Runtime Async Feature

[TheAngryByrd]

Description

Fixes #19056

This was 99% written by Oh-My-Opencode planner/executor with Opus 4.6. I'm not claiming it's good but it did make it work.

docs/samples/runtime-async-library/README.md is where to look at how to run the sample library.

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/release-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[github-actions]

❗ Release notes required

@TheAngryByrd,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/FSharp.Core	docs/release-notes/.FSharp.Core/11.0.100.md	No release notes found or release notes format is not correct
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md	No release notes found or release notes format is not correct
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md	No release notes found or release notes format is not correct

[majocha]

This is maybe the one thing that makes me uneasy.
This introduces a special case of something like a type-driven return type conversion.
I wonder if it would be possible to have a special function instead, let's say:

val __asyncReturn: 't -> Task<'t>

compiled to no-op or whatever dotnet expects for the async runtime feature.

[T-Gro]

As public API in FSharp.Core ?

[majocha]

I guess so, similar to current StateMachineHelpers. Although I gave no thought how this should behave with ns20.

[majocha]

I don't like very much that the feature resides at the level of computation expressions.
IMO it should be possible to write a working low-level runtime async method using dotnet's AsyncHelpers and some FSharp.Core helpers. Ideally runtime async CEs should compile to such code without any special treatment in CheckComputationExpressions.fs. I don't know if it's possible.

[T-Gro]

We need to encode an invariant about the retTy of the method behaving differently, while also making sure it meets the runtime verification and is only used for MethodImpl.Async methods.
If you can do that and also manually annotate your method with the right attributes, it should also work without a CE ?

(I assume your goal is the ability to write some low level primitives without a CE, and only leave runtimeTask for orchestrating bigger workflows?)

[majocha]

Yes, my thinking is basically to get it to work from first principles, so the changes to compiler are as minimal as possible. It seems no additional intrinsic functions are really needed, just an unsafe cast helper.

For example with just adding the async flag emit to the compiler the following code runs fine in net11.0

open System.Runtime.CompilerServices
open System.Threading.Tasks

module internal Helpers =
    let inline runtimeAsyncReturn<'t> (v: 't) : Task<'t> =
        (# "" v : Task<'t> #)

[<MethodImpl(MethodImplOptions.Async)>]
let asyncMethod() =
    printfn "starting"
    for x in 1 .. 5 do
        printfn "tick %d" x
        AsyncHelpers.Await (Task.Delay 1000)
    printfn "done"
    Helpers.runtimeAsyncReturn 42

asyncMethod().Result |> printfn "result: %d"

[TheAngryByrd]

Yeah, this is basically just the proof of concept I got working a while ago. I would think it might be nice to get some compiler help like saying you can't return a TaskLike from a method with [<MethodImpl(MethodImplOptions.Async)>].

[majocha]

Yes, this is exactly that. It just bothers me a bit that the rewriting happens at CheckComputationExpressions level. It would be maybe prettier to have it working at lower level. To deal with inlining, lambdas, return types generally in such a way as to allow builders to naturally use it. I don't know if it's practical to do so.

[auduchinok]

Is there a chance we could also emit the async metadata along the way? 🙂

https://github.com/dotnet/roslyn/blob/47f526de99da22b08a53d34b4dc8dba074caa61c/src/Dependencies/CodeAnalysis.Debugging/PortableCustomDebugInfoKinds.cs#L13

This would allow a much better tooling integration for stepping.

[majocha]

One observation:

  runtimeTask {
      for x = 1 to 10 do
          do! Task.Delay(500)
          printfn "tick %d" x

      printfn "Done with simple for loop"
  }

results in 2 separate cil managed async closures. One for the loop, one for the final printfn.
There are also 5 AsyncHelpers.Await calls in the generated code.

I would expect just a single method with everything inlined and just one AsyncHelpers.Wait suspension for the Task.Delay

I think the problem is that currently this PR makes CE closures themselves async only to compose them with AsyncHelpers.Wait.

I wonder if it wouldn't be better to have an explicit type representing the delayed chunks. Let's say

type RuntimeAsyncCode<'T> = delegate of unit -> 'T // maybe it can be a DU not a delegate?

This way we could inline it consistently into a single final async method with less magic.

[majocha]

Currently C# compiler allows creating runtime-async lambdas.

var f = async () => ...

creates a cil managed async method that gets correctly inlined with zero hassle.

Not having this in F# could be a limitation wrt to C# interop and performance at some point.
I have a feeling that some way of specifying a first class async function would also simplify the runtime-async CE builder story.

[T-Gro]

How would we go around the compiler/library split in that case?

Or would we abandon that and let the compiler fully learn about Task<T> ?

I am definitely open on building up a primitive in the typechecker+codegen (outside of ComputationExpressions and outside of FSharp.Core - leaving that spice for higher-level features).

What we do not have is a low-level user gesture (equivalent to compiler recognized async/await in C#).
Would a convention + intrinsic function ( prototype could start with __asyncExecute : Task<'T> -> T and inverse __asyncReturn until a better name is found)

[majocha]

How would we go around the compiler/library split in that case?

Or would we abandon that and let the compiler fully learn about Task<T> ?

I am definitely open on building up a primitive in the typechecker+codegen (outside of ComputationExpressions and outside of FSharp.Core - leaving that spice for higher-level features).

What we do not have is a low-level user gesture (equivalent to compiler recognized async/await in C#). Would a convention + intrinsic function ( prototype could start with __asyncExecute : Task<'T> -> T and inverse __asyncReturn until a better name is found)

Yes, intrinsic + convention seems like a good way around the existing limitations.

As first approximation, I'm thinking of usage like:

let clo = fun x -> __runtimeAsync<Task<'T>>(inner_expr: 'T) 

where __runtimeAsync simply causes the Invoke to be marked async and is itself erased down to the inner_expr cast to Task<'T> or any other type satisfying the runtime async spec. I think we can make it a responsibility of expert user to provide the valid return type initially.

I think we only need to worry about providing valid managed async methods, consumption is taken care of by the runtime with AsyncHelpers.Await.