Creating pre-completed Tasks

Creating pre-completed Tasks

  • Comments 23


We’ve been considering adding support for creating completed Tasks from an existing result.  Here’s a prototypical example of where this could be valuable.


void Task<float> ComputeAsync(...)
    if (!resultIsCached)
        return Task<float>.Factory.StartNew(() => Compute());
        // return a Task<float> with the cached result

The method usually returns a Task<float> that represents some compute-intensive operation that will be done asynchronously.  However, the greater code has the ability to cache results from previous operations, so there’s a chance that the requested result is already available.  If that’s the case, we just want to return a completed Task with the cached result.  Note that this can be done in .NET 4 as follows:


TaskCompletionSource<float> tcs = new TaskCompletionSource<float>();
return tcs.Task;

But we could make this easier and slightly better-performing:


return Task.FromResult(cachedResult);

So your input would help.  If you’ve got a minute, feel free to answer the following questions and/or provide any other thoughts you have:

  1. Would the convenience make this feature worthwhile?
  2. If you have code that resembles this example, is performance a huge concern (to the point that shaving a few allocations and interlocked operations off of the creation of a pre-completed Task would help)?
  3. What about support for creating other pre-completed Tasks, e.g. creating a pre-canceled Task or one from an existing Exception?  Details regarding the scenario would help here.



Leave a Comment
  • Please add 5 and 2 and type the answer here:
  • Post
  • Please add - i needed that functionality in my code ( if (dataSourceX != null) return GetDataSourceTask() else Task.FromResult(emptyResult) ) -- this construct greatly simplified all the code logic, waiting, etc. I vote to definitely include it. P.S. It took me a very long time to even find this post - Task.FromResult would have been much more intuitive.

  • Looks great, but I would love some consistency in naming - particularly with Rx. What about Task.Return() to mirror Observable.Return()?

  • I just needed this feature and found this post via google...

  • I like the idea, don't know about the optimization, but since you are planning to add new methods to task (I think), then it's a good time to do it as opposed to use a custom extension method. And I'm interested in the exception one, at least to be able to give a "NotImplementedException" a "ObjectDisposedException" or an "ArgumentException" (and sons) which are usually trivial to check and throw.

    So... how is this feature going.. about -99 yet?

  • Definitely we need it. It's extremely useful for unit testing and mocking asynch operations. In fact we already created our own class that can create tasks in certain state.

    public static Task<T> RanToCompletion<T>(T value)

    public static Task<T> Faulted<T>(Exception exception)

    public static Task<T> Canceled<T>()

  • i have made an extension method that returns a completed Task in our system. we use it for when the contract or interface expexts a task, but the perticular implementation doest not support async operation.

    i would personally find it useful to have such a method in the framework :)

  • Thanks for the great feedback, everyone!

  • How pleasant is to find at first search that the one's problem has been solved intelligently by others.

    Same case: cached data!

    Thank you.

Page 2 of 2 (23 items) 12