re: Exposing .NET tasks as WinRT asynchronous operations

Stephen Toub - MSFT — Wed, 27 Jun 2012 15:25:27 GMT

Thanks, Can. I'm glad you enjoyed the post.

re: Exposing .NET tasks as WinRT asynchronous operations

Can Bilgin — Wed, 27 Jun 2012 15:05:39 GMT

Nice post Stephen... I guess the least blogged section of WinRT is System.Threading and System.Threading.Tasks.... I was also recently blabbing about httpclient and IAsyncOperationWithProgress with chunk-ed streams. ( canbilgin.wordpress.com/.../download-send-request-asyncwithprogress-with-httpclient )

re: Exposing .NET tasks as WinRT asynchronous operations

Stephen Toub - MSFT — Mon, 18 Jun 2012 16:49:59 GMT

Hi Andy-

Both Task.Run (part of the BCL) and ThreadPool.RunAsync (part of WinRT) support offloading work to a pool of threads so as to avoid blocking the current thread while the specified computation executes.

There are some programming model differences between the two, of course. For example, Task.Run provides multiple overloads that work with different delegate types: Action, Func<TResult>, Func<Task>, and Func<Task<TResult>. The overload that accepts an Action is very similar to ThreadPool.RunAsync, in that the delegate represents a synchronous chunk of work that doesn't return a value; with this overload, Task.Run returns a Task (ThreadPool.RunAsync returns an IAsyncAction). The Task.Run overload that accepts a Func<TResult> also represents a synchronous chunk of work, but it does return a value, of type TResult; when used, Task.Run will return a Task<TResult>, such that the returned task object surfaces the result value eventually returned by the delegate's invocation.

The other two overloads that accept Func<Task> and Func<Task<TResult>> support the special (but common) case where the provided delegate does asynchronous work. If these overloads didn't exist, then if you provided a Func<Task<TResult>> delegate to Task.Run, Task.Run would return a Task<Task<TResult>>, where instead what you almost always want is a Task<TResult>; in other words, you want Task.Run to return a task that will complete when the task returned from the delegate completes, not at the moment when the delegate itself completes and returns the task. You can see this in the example used in the post: you want the task returned from Task.Run to complete when the task returned from DownloadStringAsyncInternal completes, not when the call to DownloadStringAsyncInternal synchronously returns its task (which may not yet be completed). For more information, see the related blog posts at blogs.msdn.com/.../10265476.aspx and blogs.msdn.com/.../10229468.aspx.

I hope that helps.

re: Exposing .NET tasks as WinRT asynchronous operations

Andy — Mon, 18 Jun 2012 14:36:21 GMT

Great article, thanks. You use Task.Run in one example to help with responsiveness. How should I think about this compared to ThreadPool.RunAsync. Are they basically the same?