Inline second statemachine into loop and us EC.Restore to reset context #23175
Conversation
ghost
added
the
| { | ||
| await FireOnCompleted(); | ||
| // Clear any AsyncLocals set during the request; back to a clean state ready for next request | ||
| ExecutionContext.Restore(cleanContext); |
There was a problem hiding this comment.
What happens if an exception occurs prior to this? Is the thread polluted?
There was a problem hiding this comment.
Either its caught further up; changing the response to a 4xx, 500 etc
Or it escapes this method (when the EC.Restore wouldn't run); when the whole connection is burnt and socket is shutdown.
As its running on the ThreadPool the "polluted" thread gets cleaned up when it's returned.
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
@aspnet-hello build |
|
Will fail the api is only internal currently as its not been approved/reviewed dotnet/runtime#38011 |
halter73
added
the
blocked
|
Change has been merged dotnet/runtime#40322; but don't know how fast it flows through? |
|
Not yet |
|
/azp run |
|
Commenter does not have sufficient privileges for PR 23175 in repo dotnet/aspnetcore |
|
Not yet |
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
Api was merged to runtime on 7 Jul, any idea how long its taking to flow through these days? |
|
🎉🥳 |
|
Thanks @benaadams |
dougbu
removed
the
blocked
amcasey
added
area-networking
Use EC.Restore to return to clean context rather than introducing a per request statemachine.
This allows use to use the connection request loop statemachine which is pre-allocated; and avoid one of the extra statemachines.
Requires dotnet/runtime#38011 "API Proposal: ExecutionContext.Restore(ExecutionContext? executionContext)"
/cc @stephentoub @halter73