Menu
When we are dealing with some extensibility points in ASP.NET Web API, we also deal with TAP (Task-based Programming Pattern). At some points, we want to provide a continuation to an async method with ContinueWith and we do some stuff inside the delegate that we pass onto ContinueWith.
As Brad Wilson explained here in depth that the SynchronizationContext is vital when we provide continuations. For me, the only place where I need to get back to the SynchronizationContext in ASP.NET Web API is the place where I need to play with HttpContext.Current (which is something that I would never do in an ASP.NET Web API application) and the place where I need to set some information for thread based such as Thread.CurrentPrincipal.
So the question is: Do we ever want to get back to the SynchronizationContext when we provide continuations in some extensibility points such as Message Handlers, Filters, Formatters, etc.?
384
WEB API is a better choice for simpler, light weight services. WEB API can use any text format including XML and is faster than WCF. It works the way HTTP works using standard HTTP verbs like GET, POST, PUT, DELETE for all the crud operation.
Yesterday I was trying to show how to diagnose a deadlock situation when using blocking code over async.
SynchronizationContext is a representation of the current environment that our code is running in. That is, in an asynchronous program, when we delegate a unit of work to another thread, we capture the current environment and store it in an instance of SynchronizationContext and place it on Task object.
The answer is almost always yes.
That's not to say that you're always going to use the synchronization context, but given the nature of message handlers, filters, and formatters, you can't predict whether or not they'll require the use of the SynchronizationContext in order to access the HttpContextBase.
Even with filters, where you're passed something that gives you access to the HttpContext (say through an IActionFilter implementation), that HttpContext is going to ultimately look at the current CallContext on the thread to provide the information from that instance. Because the current thread (when running async) doesn't have that information on it when you started the Task, those calls will fail.
That said, if you need general, unfettered access to HttpContextBase associated with the request, then you'll absolutely have to pass around the SynchronizationContext in order to access it.
However, if possible, you should copy the details out of the HttpContextBase that you need, and pass that around; if you're writing something very generalized, then this won't be possible.
175
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
