Propose new async API #110420

agocke · 2024-12-04T21:54:05Z

I'd appreciate everyone's thoughts on this.

This PR replaces the 'method signature' overloading with a new 'Await' method that JIT should treat as an intrinsic. The primary benefit in this case is that it makes the IL valid according to previous versions of the ECMA specification. Ideally, this should cause fewer failures in tooling that examines IL.

I'm still considering something to deal with the type-mismatch in the return type.

This PR replaces the 'method signature' overloading with a new 'Await' method that JIT should treat as an intrinsic. The primary benefit in this case is that it makes the IL valid according to previous versions of the ECMA specification. Ideally, this should cause fewer failures in tooling that examines IL.

dotnet-policy-service · 2024-12-04T21:54:51Z

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

333fred · 2024-12-04T22:13:14Z

docs/design/specs/runtime-async.md

+```C#
+  namespace System.Runtime.CompilerServices
+  {
+      public static class RuntimeHelpers


What assembly will define these? Should we restrict it to just system.private.corelib?

In practice, this class already exists and is in corelib, so we will put these in corelib. As far as ECMA is concerned, I see no reason to mandate it.

If there's no reason to mandate it, that must mean that the runtime needs to accept a user defining these helpers themselves, rather than the ones the runtime defines. That seems... Unlikely to be what you want.

stephentoub · 2024-12-05T14:12:09Z

docs/design/specs/runtime-async.md


-Callers may retrieve a Task/ValueTask return type from an async method via calling its primary, definitional signature. This functionality is available in both sync and async methods.
+These methods are also only legal to call inside async methods. These methods perform suspension like the `AwaitAwaiter...` methods, but are optimized for calling on the return value of a call to an async method. To achieve maximum performance, the IL sequence of two `call` instructions -- one to the async method and immediately one to the `Await` method -- should be preferred.


How does this interact with ConfigureAwait? It seems like 99.999% of all use of await in our core libraries would not use these specialty methods?

One of the things that the group proposed is that the runtime may be able to understand the pattern of RuntimeHelpers.Await(taskMethod().ConfigureAwait(false)) and avoid the Task materialization in that case.

Yes, but that doesn't quite fit with the proposed APIs.

The main problem is that what comes out of ConfigureAwait isn't a task, it's a ConfiguredTaskAwaitable. The only way we have of dealing with this in the current design is to use the AwaitAwaiter... API.

I agree that ConfigureAwait is something we should handle, it's just that it's not a 'new' problem with our API structure.

One option is to add an Await for ConfigureTaskAwaitable as above, and then recognize the triple sequence above.

It seems to raise a question about what the value of this Await function is, over recognizing RuntimeHelpers.AwaitAwaiterFromRuntimeAsync(Async2Function().GetAwaiter()) and RuntimeHelpers.AwaitAwaiterFromRuntimeAsync(Async2Function().ConfigureAwait(constant).GetAwaiter()).
Size comes to mind.

I suppose AwaitAwaiterFromRuntimeAsync does not really have the right shape to be used in the way we'd like here, and it's not easy to generalize it to have a shape that would be usable either.

Yes, good point. This was implicit, but let's make it explicit. I see the value of Await as:

Size of IL

Complexity (a clearer sequence to recognize. If we open up GetAwaiter we need to also think about entire blocks like if (!awaiter.IsCompleted) { awaiter.UnsafeAwaitAwaiterFromRuntimeAsync(); }. Await is comparatively simpler)

Shorter/simpler sequence for the JIT

That second point is particularly relevant. I expect that's the general pattern that Roslyn will emit for such locations.

teo-tsirpanis · 2024-12-05T15:15:28Z

the type-mismatch in the return type

Maybe also recognize the FromResult and CompletedTask APIs as intrinsics?

docs/design/specs/runtime-async.md

agocke · 2024-12-05T18:33:21Z

the type-mismatch in the return type

Maybe also recognize the FromResult and CompletedTask APIs as intrinsics?

Two things here:

I'm not sure how valuable it is. This change makes it so that current IL tools will be able to correctly bind the call instructions to async methods and presumably keep control flow going. The failure case of having a "missing" method seems like it could be problematic. Not because scanners shouldn't be able to handle it -- unresolvable calls are not unusual in C# -- but because not resolving the calls could have weird behavior. On the other hand, having a mismatched return type seems like it has a smaller breakage risk. It's not clear to me what failure we would be preventing. It's also a very simple change for any IL logic.
FromResult is a little shaky. The nice part about Await above is that we can actually make the semantics correct even in the case where intrinsification fails. It will just be slower. So if an IL compiler reorders the calls and breaks up the sequence, it should be fine. FromResult is not the same. The actual IL convention for async methods is to return the value directly. If someone took the result, called FromResult on it, stashed it in a local, then returned the value, that would be incorrect async method IL.

I think we should understand the case where we are actually helping an unaware IL rewriter keep working, vs creating a situation that makes things worse and the only fix, regardless of what we do, is for the IL rewriter to fix their code.

jakobbotsch · 2024-12-06T17:46:25Z

docs/design/specs/runtime-async.md

+          [MethodImpl(MethodImplOptions.Async)]
+          public static T Await<T>(Task<T> task);
+          [MethodImpl(MethodImplOptions.Async)]
+          public static T Await<T>(ValueTask<T> task);


I think the MethodImpl part is uninteresting for the spec – it really is an implementation detail of SPC whether or not this bit is set for these, and consumers should not be using it to make any decisions. Similarly for AwaitAwaiterFromRuntimeAsync.

333fred · 2024-12-06T17:57:34Z

docs/design/specs/runtime-async.md

      }
  }
  ```

-Each of the above methods will have semantics analogous to the current AsyncTaskMethodBuilder.AwaitOnCompleted/AwaitUnsafeOnCompleted methods. After calling this method, it can be presumed that the task has completed. These methods are only legal to call from inside async methods.
+These methods are only legal to call inside async methods. The `...AwaitAwaiter...` methods will have semantics analogous to the current `AsyncTaskMethodBuilder.AwaitOnCompleted/AwaitUnsafeOnCompleted` methods. After calling either method, it can be presumed that the task or awaiter has completed. The `Await` methods perform suspension like the `AwaitAwaiter...` methods, but are optimized for calling on the return value of a call to an async method. To achieve maximum performance, the IL sequence of two `call` instructions -- one to the async method and immediately one to the `Await` method -- should be preferred.


These methods are only legal to call inside async methods

From a language perspective, we'd probably have to make an actual change to C# enforce this as a compiler error. We could do a warning without any issue though.

agocke requested review from 333fred, jakobbotsch and VSadov December 4, 2024 21:54

dotnet-issue-labeler bot added the area-Meta label Dec 4, 2024

dotnet-policy-service bot assigned agocke Dec 4, 2024

333fred reviewed Dec 4, 2024

View reviewed changes

stephentoub reviewed Dec 5, 2024

View reviewed changes

teo-tsirpanis reviewed Dec 5, 2024

View reviewed changes

docs/design/specs/runtime-async.md Outdated Show resolved Hide resolved

agocke added 2 commits December 5, 2024 10:13

Change return type of AwaitAwaiter methods to void

9757697

Reword suspension

358aec6

jakobbotsch reviewed Dec 6, 2024

View reviewed changes

333fred reviewed Dec 6, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Propose new async API #110420

Propose new async API #110420

agocke commented Dec 4, 2024

dotnet-policy-service bot commented Dec 4, 2024

333fred Dec 4, 2024

agocke Dec 5, 2024

333fred Dec 5, 2024

stephentoub Dec 5, 2024

333fred Dec 5, 2024

stephentoub Dec 5, 2024

agocke Dec 5, 2024 •

edited

Loading

jakobbotsch Dec 5, 2024

jakobbotsch Dec 5, 2024

agocke Dec 5, 2024 •

edited

Loading

333fred Dec 5, 2024

teo-tsirpanis commented Dec 5, 2024

agocke commented Dec 5, 2024

jakobbotsch Dec 6, 2024

333fred Dec 6, 2024


		Callers may retrieve a Task/ValueTask return type from an async method via calling its primary, definitional signature. This functionality is available in both sync and async methods.
		These methods are also only legal to call inside async methods. These methods perform suspension like the `AwaitAwaiter...` methods, but are optimized for calling on the return value of a call to an async method. To achieve maximum performance, the IL sequence of two `call` instructions -- one to the async method and immediately one to the `Await` method -- should be preferred.

Propose new async API #110420

Are you sure you want to change the base?

Propose new async API #110420

Conversation

agocke commented Dec 4, 2024

dotnet-policy-service bot commented Dec 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agocke Dec 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agocke Dec 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

teo-tsirpanis commented Dec 5, 2024

agocke commented Dec 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agocke Dec 5, 2024 •

edited

Loading

agocke Dec 5, 2024 •

edited

Loading