This question already has an answer here:
- Fire-and-forget with async vs “old async delegate” 4 answers
I've been pouring through MSDN docs all day, and their philosophy of asynchronous coding is confusing me. As I understand it, the thread that calls the async method will not be blocked if the async method is called. Yet, async is always paired in examples with await, which appears to negate the async-ness, making it so that the outer method DOES have to wait for the code to execute anyway. Shouldn't I be able to call an async method and then continue with the execution of the outer method?
This is the scenario I've been encountering, more or less:
void reportSomethingHappened(info)
- Collect info
- HTTP POST info to logging server (ie. mixpanel, sentry)
And here would be a calling method:
void largerProcess
if (whatever)
reportSomethingHappened();
bla;
bla;
As far as I understand, since POST requests can be done asynchronously, I should be able to make reportSomethingHappened() into an async method (by, AFAIK, await-ing the webrequest, and adding the async keyword).
But the largerProcess method doesn't need to wait for (ie. await) the reporting method to finish in order to execute bla bla. Yet, VS tells me that with an async method I can either await it, or it will happen synchronously, and block. Doesn't that defeat the purpose of doing it separately?
How do I write this so that reportSomethingHappened doesn't block execution of largerProcess? (Which is inherently confusing me, because I thought that was the point of async all along)