-
Notifications
You must be signed in to change notification settings - Fork 833
WIP Async2 #18873
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP Async2 #18873
Conversation
... binary (FS2014)
❗ Release notes requiredCaution 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:
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
|
To avoid confusion - it's not the same "async2" as in runtime-supported async. It's just different re-implementation of async, right?
To avoid confusion - it's not the same "async2" as in runtime-supported async. It's just different re-implementation of async, right?
Nope, no. I wasn't even aware this was a thing until now :) The goal is to possibly replace all the internal use of async and cancellable with one reasonably efficient resumable CE. I went with async2 name after the example in resumable code RFC.
LOL, probably before I ever finish this, the runtime async model will switch to https://github.com/dotnet/runtimelab/blob/feature/async2-experiment/docs/design/features/runtime-handled-tasks.md
I guess this is the fate, always catching up :)
Implementing fast tail call with ReturnFromFinal
is tricky While we can abandon intermediate computations in a tail call chain, we cannot abandon the first one, we must return to it, because it is the one actually awaited.
One possible solution is to thread a IValueTaskSource
context between tail calls. We can bind to a ValueTask
in the initial ReturnFromFinal
, set the value in the last call of the chain, dropping all the intermediate computations.
I went simply with TaskCompletionSource as a tail-call context. With ReturnFromFinal
the overhead is now significantly lower.
140b118
to
f2ba059
Compare
Uh oh!
There was an error while loading. Please reload this page.
Currently just replaces cancellable.
Features: cold start, multi-start, cancellable, trampolined binds for safe non-tail recursion, fast tail-recursion with
ReturnFromFinal
, exceptions cached in ExceptionDispatchInfo for fast recovery from deep call stacks.Synchronous executions should be quite fast and low alloc when it's done, but there are some fixes needed:
Currently complex mut rec expressions are not statically compiled, see the nowarn in
CheckDeclarations.fs
.Very initial work.