[RuntimeAsync] Model async continuation definition via delay-free #3090
Conversation
Instead of introducing a new mechanism to mark the async continuation register as busy until a kill we can keep use the delay-free mechanism, provided we take a bit care about where we insert the ref positions and about ensuring the async continuation ends up in the right spot.
jakobbotsch
changed the title
|
cc @VSadov |
| } | ||
|
|
||
| BlockRange().Remove(asyncCont); | ||
| BlockRange().InsertAfter(node, asyncCont); |
There was a problem hiding this comment.
If we go backwards from continuation to find the call, why do we need to force the order? Would it be "after" anyways?"
There was a problem hiding this comment.
I see - to make sure there is nothing in between.
| { | ||
| MarkAsyncContinuationBusyForCall(call); | ||
| } | ||
|
|
There was a problem hiding this comment.
Should another MarkAsyncContinuationBusyForCall below be deleted?
jakobbotsch
merged commit 030e62c
into
dotnet:feature/async2-experiment
|
After fetching from the async-experiment am getting an assert on x86. |
|
No, changes from this PR wouldn't have any effect during the async transformation. This is likely a latent bug that is now showing up after merging because of recent JIT flowgraph changes (e.g. dotnet/runtime#114016). I will take a look when time permits. |
|
I think I have run x86 since the merge, but maybe I didn't or scenario needs some more conditions that were not there. |
2 participants
Instead of introducing a new mechanism to mark the async continuation register as busy until a kill we can use the delay-free mechanism, provided we take a bit care about where we insert the ref positions and about ensuring the async continuation ends up in the right spot.