What is the use for Task.FromResult<TResult> in C#

What is the use for Task.FromResult<TResult> in C#

问题

In C# and TPL (Task Parallel Library), the Task class represents an ongoing work that produces a value of type T.

I'd like to know what is the need for the Task.FromResult method ?

That is: In a scenario where you already have the produced value at hand, what is the need to wrap it back into a Task?

The only thing that comes to mind is that it's used as some adapter for other methods accepting a Task instance.

评论

To some extent I agree with that, but the creation of dense, useful, consolidated, discsussion-oriented pages like this is a huge benefit. I almost always learn more from a good, dense stackoverflow page than from googling and doing research across multiple places, so in this case, I'm really glad he posted this.

– Alex Edelstein

Jan 14, 2016 at 17:43

回答1

There are two common use cases I've found:

1. When you're implementing an interface that allows asynchronous callers, but your implementation is synchronous.
2. When you're stubbing/mocking asynchronous code for testing.

Stephen Cleary

评论

A good case for #1 is a web service. You could have a synchronous service method that returns Task.FromResult and a client that awaits asynchronously for the network I/O. This way you can share the same interface between client/server using ChannelFactory.

– Nelson Rothermel

Sep 25, 2014 at 21:25

For instance the ChallengeAsync method. WTF were the designers at MS thinking? There is absolutely no reason for this method to return a Task. And all the sample code from MS simply has FromResult(0). Hopefully the compiler is smart enough to optimize this away, and doesn't actually spawn a new thread and then kill it right away!

– John Henckel

Jan 29, 2015 at 17:18

 

@JohnHenckel: OWIN is designed from the ground up to be async-friendly. Interfaces and base classes often use async signatures because it just allows (not forces) the implementation to be async. So it's similar to IEnumerable<T> deriving from IDisposable - it allows the enumerable to have disposable resources, not forces it to. Neither FromResult, async, nor await will spawn threads.

– Stephen Cleary

Jan 29, 2015 at 19:13

 

@StephenCleary hmhm, thanks for explaining that. I had assumed that await would spawn, but I tried it and I see it doesn't. Only Task.Run does. Therefore, x = await Task.FromResult(0); is equivalent to saying x = 0; that's confusing, but good to know!

– John Henckel

Jan 29, 2015 at 22:22

回答2

One example would be a method that makes use of a cache. If the result is already computed, you can return a completed task with the value (using Task.FromResult). If it is not, then you go ahead and return a task representing ongoing work.

Cache Example: Cache Example using Task.FromResult for Pre-computed values

回答3

Use it when you want to create an awaitable method without using the async keyword. I found this example:

public class TextResult : IHttpActionResult
{
    string _value;
    HttpRequestMessage _request;

    public TextResult(string value, HttpRequestMessage request)
    {
        _value = value;
        _request = request;
    }
    public Task<HttpResponseMessage> ExecuteAsync(CancellationToken cancellationToken)
    {
        var response = new HttpResponseMessage()
        {
            Content = new StringContent(_value),
            RequestMessage = _request
        };
        return Task.FromResult(response);
    }
}

Here you are creating your own implementation of the IHttpActionResult interface to be used in a Web Api Action. The ExecuteAsync method is expected to be asynchronous but you don't have to use the async keyword to make it asynchronous and awaitable. Since you already have the result and don't need to await anything it's better to use Task.FromResult.

回答4

From MSDN:

This method is useful when you perform an asynchronous operation that returns a Task object, and the result of that Task object is already computed.

http://msdn.microsoft.com/en-us/library/hh228607.aspx

Why use Task.FromResult<T>(T result) from a method that contains awaits?

问题

I came across the following method in a tutorial;

    private async Task<ClaimsIdentity> GetClaimsIdentity(string userName, string password)
    {
        if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(password))
            return await Task.FromResult<ClaimsIdentity>(null);

        // get the user to verifty
        var userToVerify = await _userManager.FindByNameAsync(userName);

        if (userToVerify == null) return await Task.FromResult<ClaimsIdentity>(null);

        // check the credentials
        if (await _userManager.CheckPasswordAsync(userToVerify, password))
        {
            return await Task.FromResult(_jwtFactory.GenerateClaimsIdentity(userName, userToVerify.Id));
        }

        // Credentials are invalid, or account doesn't exist
        return await Task.FromResult<ClaimsIdentity>(null);
    }

The author always uses await Task.FromResult<ClaimsIdentity>(...) even when returning null. I'm no expert in the Task-await pattern and would have written the method something like this;

    private async Task<ClaimsIdentity> GetClaimsIdentity(string userName, string password)
    {
        if (string.IsNullOrEmpty(userName) || string.IsNullOrEmpty(password))
            return null;

        // get the user to verifty
        var userToVerify = await _userManager.FindByNameAsync(userName);

        if (userToVerify == null) return null;

        // check the credentials
        if (await _userManager.CheckPasswordAsync(userToVerify, password))
        {
            return _jwtFactory.GenerateClaimsIdentity(userName, userToVerify.Id);
        }

        // Credentials are invalid, or account doesn't exist
        return null;
    }

Both compile. What is the difference (if any) between these two methods? Is there anything to be gained by using await Task.FromResult<ClaimsIdentity>(null) in this manner?

评论

This constructs a new task around the result that has already completed, so no, there is no point in using Task.FromResult in this case. This method is for use in non-async methods that return tasks.

– Lasse V. Karlsen

Feb 10, 2020 at 8:30

回答1

According to the best stackoverflow answer I've found about Task.FromResult: https://stackoverflow.com/a/19696462/6440521

The usage of Task.FromResult is appropriate only in the context of synchronous methods and mocking. So using it in an async method when you just want to return a result is redundant - gives you no additional benefits, also AsyncGuidance does not say anything about using Task.FromResult in an async method: https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

So AFAIK using Task.FromResult in an async method is unnecessary, bloats your code and gives you no real benefits.

Task.FromResult() vs. Task.Run()

I've come across quite a few situations lately where async methods execute synchronously, but return a Task anyway, so they can be awaited, e.g.

public virtual Task CreateAsync(TUser user)
{
    ThrowIfDisposed();
    if (user == null) throw new ArgumentNullException("user");
    Context.Save(user);
    Context.Flush();
    return Task.FromResult(0);
}

Surely it is better to dispatch the probably-long-running operation to a thread and return the still active task, to genuinely be awaited:

public virtual Task CreateAsync(TUser user)
{
    ThrowIfDisposed();
    if (user == null) throw new ArgumentNullException("user");
    return Task.Run(() =>
    {
        Context.Save(user);
        Context.Flush();
    });
}

I some suspicion, though, that just spinning off TPL threads isn't the safest practice. Any commentary on these two different patterns?

回答1

If your method is synchronous you shouldn't return a Task to begin with. Just create a traditional synchronous method.

If for some reason that's not possible (for example, you implement some async interface) returning a completed task using Task.FromResult or even better in this case Task.CompletedTask (added in .NET 4.6) is much better than using Task.Run in the implementation:

public virtual Task CreateAsync(TUser user)
{
    // ...
    return Task.CompletedTask;
}

If the consumer of your API cares strongly about the Task-returning method not running synchronously they can use Task.Run themselves to make sure.

You should keep in mind that async methods may have a considerable synchronous part (the part before the first await) even if they do eventually continue asynchronously. You can't assume async methods return a Task immediately anyway.

回答2

ask.FromResult doesn't actually creates or runs a task but it just wraps the returned result in a task object. I personally used it in Unit Tests where I need to simulate the Async methods and Of course I wouldn't want to run actual tasks in Unit tests.

Besides Task.Run will actually create a task and run a task on TaskScheduler. It is not recommended to use Task.Run when you're doing Async programming. Rather use await on tasks. See few do's and don't of Tasks by Stephen Cleary.