Menu
Trying to use new C# 5 async model it was surprising to me AspNetSynchronizationContext is an internal class (as well as AspNetSynchronizationContextBase base). Thus undocumented. But it's essential to know what it does when utilizing async/await feature within your ASP.NET code. Am I correct that It does guarantee your continuations will get the same HttpContext.Current as original callers? It does not guarantee the continuations will execute on the same thread as the callers?
If the latter assumption is not true and I get the original thread can I be sure to get the same thread context in continuations? I mean principal/culture associated with the thread and thread local storage? That's important because ASP.NET localization relies on thread's culture and my application relies on .NET role security model (thread's principal).
970
SynchronizationContext basically is a provider of callback delegates' execution. It is responsible for ensuring that the delegates are run in a given execution context after a particular portion of code (encapsulated inside a Task object in . Net TPL) in a program has completed its execution.
We don't have the SynchronizationContext in ASP.NET Core applications. ASP.NET Core avoids capturing and queuing the context, all it does is taking the thread from a thread pool and assigning it to the request. So, a lot less background works for the application to do.
ASP.NET Core doesn't have SynchronizationContext . So how can the continuation of async code resume to where it begin (the original thread)?
Am I correct that It does guarantee your continuations will get the same HttpContext.Current as original callers? It does not guarantee the continuations will execute on the same thread as the callers?
Yes, HttpContext.Current is preserved, and yes, the continuations may execute on a different thread.
I mean principal/culture associated with the thread and thread local storage? That's important because ASP.NET localization relies on thread's culture and my application relies on .NET role security model (thread's principal).
Ordinary thread-local storage is lost. You can mitigate this by using LogicalCallContext (which flows with ExecutionContext), but with async it's easier to just reference the variables directly.
Principal is always preserved; to do otherwise would be a security risk. This flows with ExecutionContext.
I believe that culture flows with AspNetSynchronizationContext, but I haven't tested this out on .NET 4.5's new implementation.
You may find my MSDN article on SynchronizationContext helpful. It's not official documentation (I don't work for Microsoft), but at least it's something. Note that the AspNetSynchronizationContext referenced in that article is now called LegacyAspNetSynchronizationContext in .NET 4.5.
Another great resource is Stephen Toub's ExecutionContext vs. SynchronizationContext.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
