-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Save and restore Thread.CurrentThread._synchronizationContext
for synchronous runtime async calls
#117725
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
Save and restore Thread.CurrentThread._synchronizationContext
for synchronous runtime async calls
#117725
Conversation
Replace `GenTree::DefinesLocal` by a `GenTree::VisitLocalDefs` to prepare for being able to allow a single node to have multiple definitions. Update uses to use the new function.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs
Show resolved
Hide resolved
cc @dotnet/jit-contrib PTAL @AndyAyersMS This implements my last known piece of JIT-side compatibility/correctness for runtime async. With this I believe we should be fully compatible with async 1, but of course many pieces of optimizations are missing (and also there may be bugs). cc @VSadov @agocke too. @agocke this will probably regress your benchmark somewhat due to the added ceremony around |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Left a few notes that can be handled in a follow-up.
/ba-g Infra timeout, succeeded earlier |
@VSadov Any other feedback here? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
This implements the remaining handling: saving and restoring
Thread.CurrentThread._synchronizationContext
around runtime async calls that finish synchronously. Lots of trickiness in representing this in the JIT. We introduce a new "suspended indicator" local that is defined by async calls and that the front end uses when it expands IR that restores the field.Plenty of optimization opportunities remaining, including a simple jump threading optimization we should be able to do to make the suspension indicator variable disappear in common cases (all cases except when resuming with an exception).
Note: it might be beneficial to read my comment below to get a better understanding on what the IR being expanded by the JIT corresponds to.