c# 我可以使用可丢弃来避免等待异步 function 调用吗？

Question

I have a synchronous function GetUserStatus() which in turn calls an async function LogAsync() .

I do not want to await on LogAsync() but that doesn't seem to be something done as simple as it is to declare await. I was just hoping it's a matter of not awaiting, but no.

I know there are approaches like using .ContinueWith() , but in this particular case I want to know if just discarding the call to LogAsync() will let the current thread continue without waiting on LogAsync() to complete?

---

Preferred pseudocode Setup :

Public UserStatus GetUserStatus(){
    var status = GenerateStatus();
    _logger.LogAsync("Current Status: " + status.description()); //invoke and forget
    return status;
}

---

Reality pseudocode :

Public async UserStatus GetUserStatus(){
    var status = GenerateStatus();
    await _logger.LogAsync("Current Status: " + status.description()); //I don't want to wait for this
    return status;
}

---

Will using discardable work like this? :

Public UserStatus GetUserStatus(){
    var status = GenerateStatus();
    _ = _logger.LogAsync("Current Status: " + status.description()); //will this await?
    return status;
}

In this last case, will GetUserStatus() wait for LogAsync() or will it just continue right after the call?

Answer 1

The simple answer is: yes, you can use a discarable to avoid waiting for LogAsync to complete. (You don't technically need to use the discard, but doing so avoids a compiler warning telling you that you're not awaiting it.)

However, you should understand what's actually happening before you do that.

What spender is saying in the comments is that all asynchronous methods start running synchronously, and will return at the first await that acts on an incomplete Task . In a method like LogAsync , that would be whenever it stores the log entry to whatever storage medium it's going to (file system or database, for example). Once that I/O request is started , then it returns and GetUserStatus can continue. Usually, that's fine. The code before the I/O request is usually very minimal.

If you really wanted to not wait for any of the code in LogAsync , then you could move it to a new thread:

_ = Task.Run(() => _logger.LogAsync("Current Status: " + status.description()));

However, that's not free (there is overhead to that). And if this is an ASP.NET application, that's not a great idea since ASP.NET has a limited number of threads so, depending on the load of your application, it may bring you dangerously close to hitting that max. In my opinion, it's not worth it. I don't think you'll be gaining anything.

The dangers

This whole idea is called "fire and forget". The "forget" is the danger that you need to weigh. Because you're forgetting it, you have no way to know if it completed successfully. It could be a database error for example, but also, in the case of ASP.NET, if the app pool is ever restarted, IIS will kill the process once it knows that all HTTP requests have finished processing. It has no idea if any background jobs are running (like a fire and forget task). So there is the possibility of it being killed.

The logging could fail and you'll never know. Sure, 99.9999% of the time it'll be fine. But only you can answer if you can tolerate any log messages being lost without you ever knowing.

If you want to mitigate that risk, there are other ways of handling it in ways that can be more described like "do this later" rather than "fire and forget". One library that helps with that is Hangfire (I've never used it, but I've seen it discussed).