What’s new in Beta 2 for the Task Parallel Library? (2\/3)<\/A><\/FONT><\/DIV><\/LI><\/UL>\nLast time, we covered Tasks being detached by default and some refactorings in our multiple-Task continuation APIs. <\/SPAN>The final post of this series will discuss Nested Tasks and Unwrap<\/B>, a Parallel namespace change<\/B>, and some changes under the covers<\/B>.<\/FONT><\/FONT><\/P>\nNested Tasks and Unwrap<\/FONT><\/FONT><\/FONT><\/H2>\nWe\u2019ve added the Unwrap APIs to address scenarios that deal with nested Tasks. <\/SPAN>Before jumping into Unwrap, let\u2019s first talk about nested Tasks, e.g. a Task<Task> or Task<Task<TResult>>. <\/SPAN>For example:<\/FONT><\/FONT><\/P>\nvar nestedTask = Task.Factory.StartNew(() =>
{
<\/SPAN>return Task.Factory.StartNew(() =>
<\/SPAN>{
<\/SPAN>return 42;
<\/SPAN>});
});<\/SPAN><\/SPAN><\/B><\/SPAN><\/P>\nNested Tasks commonly lead to unexpected behavior in applications. <\/SPAN>For example, consider an API that provides the following functionality for asynchronously logging into a web service (like one from Facebook), retrieving a list of friends, and sending an email to each friend.<\/FONT><\/FONT><\/SPAN><\/P>\n\/\/ Given a user name and password, returns a Task whose<\/SPAN><\/P>\n\/\/ result is a UserToken object.<\/SPAN><\/P>\npublic Task<UserToken> LogOn(string username, string password);<\/SPAN><\/P>\n <\/SPAN><\/P>\n\/\/ Given a UserToken, returns a Task whose result<\/SPAN><\/P>\n\/\/ is a collection of Friend objects.<\/SPAN><\/P>\npublic Task<FriendCollection> GetFriendList(UserToken userToken);<\/SPAN><\/P>\n <\/SPAN><\/P>\n\/\/ Given a Friend, subject, and body, returns a Task that<\/SPAN><\/P>\n\/\/ represents an email sending operation.<\/SPAN><\/P>\npublic Task SendEmail(Friend friend, string subject, string body);<\/SPAN><\/P>\n <\/SPAN><\/P>\nA user would like to be able to write code like the following, utilizing these APIs and Task continuations:<\/FONT><\/FONT><\/SPAN><\/P>\nvar userToken = LogOn(user, pass);<\/SPAN><\/P>\nvar friends = userToken.ContinueWith(_ => GetFriendList(userToken.Result));<\/B><\/SPAN><\/P>\nvar emails = friends.ContinueWith(_ =><\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>var sentMails = new List<Task>();<\/SPAN><\/P>\n <\/SPAN>foreach(var friend in friends.Result)<\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>sentMails.Add(SendEmail(friend, subject, body));<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n <\/SPAN>return Task.Factory.ContinueWhenAll(<\/SPAN><\/P>\n <\/SPAN>sentMails.ToArray(), tasks => Task.WaitAll(tasks));<\/SPAN><\/P>\n});<\/SPAN><\/P>\nemails.ContinueWith<\/B>(_ => Console.WriteLine(\u201cAll emails sent\u201d));<\/SPAN><\/P>\n <\/SPAN><\/P>\nThe bolded code is problematic. <\/SPAN>Because the GetFriendList method returns a Task<FriendCollection>, the \u2018friends\u2019 variable is actually going to be a Task<Task<FriendCollection>>. <\/SPAN>This will cause a compiler error at the foreach loop, because \u2018friends.Result\u2019 will return a Task<FriendCollection> instead of a FriendCollection. <\/SPAN>The compiler error in this case is a good thing, of course, highlighting a programming error. <\/SPAN>However, once a developer realizes the type mismatch, he still has to code additional logic to unwrap the \u2018friends\u2019 Task so that it returns an actual FriendCollection. <\/SPAN>This logic is nontrivial, especially if it is to correctly deal with exceptions, cancellation, etc. <\/SPAN>The last line is also problematic. <\/SPAN>The emails variable here is actually of type Task<Task>. <\/SPAN>The outer Task will complete once the inner Task is returned from its body, even if the inner Task hasn\u2019t completed. <\/SPAN>The net result of this is that \u201cAll emails sent\u201d could be written out prior to all of the email tasks actually completing.<\/FONT><\/FONT><\/SPAN><\/P>\nNow, you may have noticed that, in Beta 1, we provided special ContinueWith overloads to deal with this type of scenario. <\/SPAN>For example:<\/FONT><\/FONT><\/SPAN><\/P>\npublic Task<TResult> ContinueWith<TResult>(<\/SPAN><\/P>\n <\/SPAN>Func<Task, Task<TResult>> continuationFunction);<\/SPAN><\/P>\n <\/SPAN><\/P>\nThe Func returns a Task<TResult>, so normally, ContinueWith would return a Task<Task<TResult>>. <\/SPAN>But this ContinueWith overload does some magic under the covers to return a Task<TResult>. <\/SPAN>There were a number of reasons why we didn\u2019t like this approach, including:<\/FONT><\/FONT><\/P>\n\u00b7<\/FONT> <\/SPAN><\/SPAN><\/SPAN>Too much magic.<\/B> <\/SPAN>It\u2019s hard to explain why one set of ContinueWith overloads is \u201cjust different\u201d.<\/FONT><\/FONT><\/P>\n\u00b7<\/FONT> <\/SPAN><\/SPAN><\/SPAN>Only works for ContinueWith<\/B>. <\/SPAN>What if user scenarios result in nested Tasks for other Task creation APIs like StartNew, ContinueWhenAll, etc.?<\/FONT><\/FONT><\/P>\n\u00b7<\/FONT> <\/SPAN><\/SPAN><\/SPAN>What if nested Tasks are actually desired<\/B>? <\/SPAN><\/B>If a user actually wants that Task<Task<TResult>>, he still might unknowingly bind to this magical overload.<\/FONT><\/FONT><\/P>\nGiven these reasons, our solution for Beta 2 and beyond is two Unwrap extension methods.<\/FONT><\/FONT><\/P>\nnamespace System.Threading.Tasks<\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>public static class TaskExtensions<\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>public static Task Unwrap(<\/SPAN><\/P>\n <\/SPAN> <\/SPAN>this Task<Task> task);<\/SPAN><\/P>\n <\/SPAN>public static Task<TResult> Unwrap<TResult>(<\/SPAN><\/P>\n <\/SPAN> <\/SPAN>this Task<Task<TResult>> task);<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n}<\/SPAN><\/P>\n <\/SPAN><\/P>\nThese methods may be used to transform any Task<Task> or Task<Task<TResult>> into a Task or Task<TResult>, respectively. <\/SPAN>The transformation performed produces a Task or Task<TResult> that fully represents the original nested Task, including exceptions, cancellation state, etc. <\/SPAN><\/FONT><\/FONT><\/P>\nWith Unwrap, we can fix the above scenario (note the bolded).<\/FONT><\/FONT><\/P>\nvar userToken = LogOn(user, pass);<\/SPAN><\/P>\nvar friends = userToken.ContinueWith(<\/SPAN><\/P>\n <\/SPAN>_ => GetFriendList(userToken.Result)).Unwrap();<\/B><\/SPAN><\/P>\nvar emails = friends.ContinueWith(_ =><\/SPAN><\/P>\n{<\/SPAN><\/P>\n <\/SPAN>var sentMails = new List<Task>();<\/SPAN><\/P>\n <\/SPAN>foreach(var friend in friends.Result)<\/SPAN><\/P>\n <\/SPAN>{<\/SPAN><\/P>\n <\/SPAN>sentMails.Add(SendEmail(friend, subject, body));<\/SPAN><\/P>\n <\/SPAN>}<\/SPAN><\/P>\n <\/SPAN>return Task.Factory.ContinueWhenAll(<\/SPAN><\/P>\n <\/SPAN>sentMails.ToArray(), tasks => Task.WaitAll(tasks));<\/SPAN><\/P>\n}).Unwrap();<\/B><\/SPAN><\/P>\nemails.ContinueWith(_ => Console.WriteLine(\u201cAll emails sent\u201d));<\/SPAN><\/P>\n <\/SPAN><\/P>\nParallel Namespace Change<\/FONT><\/FONT><\/FONT><\/H1>\nWe\u2019ve moved the Parallel class from the System.Threading namespace to the System.Threading.Tasks<\/B> namespace. <\/SPAN>We found that most applications needed to bring in both namespaces when using TPL, so why not put everything into one namespace? <\/SPAN>Additionally, Parallel is such a common word (and will likely become more so in the future), and System.Threading such a common namespace, we wanted to reduce the chances of conflict with other .NET types as much as possible.<\/FONT><\/FONT><\/P>\n