This project is read-only.

What does Web API do while waiting for an async service operation to complete?

Topics: Web Api
Jan 10, 2012 at 11:21 AM

I understand the benefits of writing an async controller in MVC, because I understand what MVC is doing while it's waiting: it returns the original ASP.NET thread to the pool so that it can service other requests.  Then when the async controller operation completes, an ASP.NET thread is retrieved anew from the pool, to finalize the request.  This is explained very well here.

In the case of WCF Web API, what is it doing while waiting for a service operation that returns Task<TResult> to complete?  Is it doing something akin to MVC?  Or has it blocked the original thread?

I have looked at the source, but I couldn't work it out.

Does WCF Web API do something very much like MVC async controllers, but only if it's hosted by MVC?

I'd like to know because I'm considering writing all my service operations to return Task<TResult>, but only if there's a clear benefit that I can understand (as there is with MVC async controllers).

Jan 10, 2012 at 12:07 PM

I believe that the benefits are exactly the same, and are available with both ASP.NET or self-hosting. The thread that was used to call the operation is not blocked waiting for the Task<TResult> (returned by the operation) to complete.

Note that Web API uses the much simpler Task model, where you only define *one* method per operation, and not the Event-based Asynchronous Pattern




Jan 10, 2012 at 1:01 PM

Hi Pedro,

That's good to know; thanks a lot.  Without the original thread being returned to the pool, I was struggling to see the benefit of Task<TResult>.  Do you have a reference for what Web API is doing, or did you spelunk the source?

Simpler Task model... yes, I'm going to learn this now.  Looks like async controller actions in MVC 4 will go the same way, and be rolled into one method.