SynchronizationContext and ASP.NET Web API Extensibility Points

Question

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.?

Answer 1

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.