[RuntimeAsync] Make Async marker a bit in MethodImpl flags #110274
Conversation
|
Tagging subscribers to this area: @dotnet/area-meta |
docs/design/specs/runtime-async.md
Outdated
| @@ -11,7 +11,7 @@ These are proposed modifications to the ECMA-335 specification for runtime-async | |||
|
|
|||
| ### I.8.4.5 Sync and Async Methods | |||
|
|
|||
| Methods may be either 'sync' or 'async'. Async method definitions are methods with a return type of `System.Threading.Task`, `System.Threading.ValueTask`, `System.Threading.Task<T>`, or `System.Threading.ValueTask<T>` attributed with `[System.Runtime.CompilerServices.RuntimeAsyncMethodAttribute]`. Async method definitions are only valid inside async-capable assemblies. An async-capable assembly is one which references a corlib containing an `abstract sealed class RuntimeFeature` with a `public const string` field member named `Async`, or a corelib meeting these requirements. The `RuntimeAsyncMethodAttribute` should only be applied to methods, and may be defined in any assembly. Inside async method bodies, certain methods are also invokable by a special signature encoding, described in [### I.8.6.1.5 Method signatures]. | |||
| Methods may be either 'sync' or 'async'. Async method definitions are methods with CIL implementation and with a return type of `System.Threading.Task`, `System.Threading.ValueTask`, `System.Threading.Task<T>`, or `System.Threading.ValueTask<T>` attributed with `[MethodImpl(MethodImplOptions.Async)]`. The `[MethodImpl(MethodImplOptions.Async)]` has no effect outside of this pattern. Async method definitions are only valid inside async-capable assemblies. An async-capable assembly is one which references a corlib containing an `abstract sealed class RuntimeFeature` with a `public const string` field member named `Async`, or a corelib meeting these requirements. Inside async method bodies, certain methods are also invokable by a special signature encoding, described in [### I.8.6.1.5 Method signatures]. | |||
There was a problem hiding this comment.
- We may want to exclude property/event accessors from this. (anything else?)
- Many questionable things like
.ctor,..cctor,~Finalize()are effectively excluded, since they would not fit the Task-returning pattern. Asyncappears incompatible withSynchronized, or at least a quite terrible combination. (anything else?)
There was a problem hiding this comment.
Also note that CIL implementation requirement would exclude delegate Invoke method, since it is runtime-provided.
I do not think it is a problem, semantically.
An async method (runtime or not) should be able to call another async method (runtime or not) via a delegate that returns a Task.
Avoiding materializing a Task when having runtime async on both sides of the delegate invocation could be an interesting challenge though.
I think it is a separate discussion. It is one of the items in #109632
There was a problem hiding this comment.
I've added obvious restrictions on use of Async - such as not valid with Synchronized and varargs. We may add more as we get into details of the feature.
I've added a follow up item about event and property accessors. We may want to forbid those to be async, but I am not sure if that is easily enforceable. It feels like it goes out of the scope of a change whose main purpose is to switch Async marker to be a MethodImpl
|
I wonder if |
I don't think this attribute is meant to be used by users directly, instead async methods returning a |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
|
Re: For now I will merge the PR as it is, so that we could make further progress on the broader picture before refining various details. |
…0274) * Make Async marker a bit in MethodImpl flags * Linter error * PR feedback Co-authored-by: Jan Kotas <jkotas@microsoft.com> * Update runtime-async.md * style tweaks --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
…0274) * Make Async marker a bit in MethodImpl flags * Linter error * PR feedback Co-authored-by: Jan Kotas <jkotas@microsoft.com> * Update runtime-async.md * style tweaks --------- Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Addresses one of design issues in: #109632
As discussed in: #104063 (comment)
This would change the Async marker to be a
MethodImplbit instead of an ordinaryRuntimeAsyncMethodAttribute.There are similarities with prior use of
MethodImplbits that direct the JIT/AOT/Interpreter to implement enhanced behavior while using the IL method body as a "blueprint" - I.E.SynchronizedThere are certain conveniences for the runtime checks for whether a method is Async if the marker is a
MethodImpl- no need to worry about attribute parsing, the location of the attribute definition, deal with attribute absence or presence of multiple attributes.