i see what you were getting at now. i find the way it's worded to be confusing, but could be a me thing. that delay is definitely awaited, but the task doesn't happen to finish before the application exits. await can be used to mean both the beginning and end state of a task, but most commonly it refers to the beginning...you await a thing and the compiler builds up the continuation for you. Here you were referring to awaiting being the continuation after the result...this isn't a great way to think about it, cause it makes people think the execution is "blocked"
I think the confusion arises because we didn't have a consensus about the very idea of "awaiting".
I will try to rephrase the word "awaiting". If there is an await operator after an async method or its returned task, the compiler will store rest of code with its context and return a task (which will contain return value of rest of code in future) immediately to caller. The rest of the code will be executed only when that async method completes .
If there is no await operator after that async method, it is like fire and forgot. Rest of the code will be executed immediately without returning of async method.
I think Paula Fahmy is saying that. Any way async method will run (some thread will work there, doing // task delay(3000);// ) but caller of non awaiting async method will forgot about it and do next thing immediately.
There are awaits in the nesting, so something is being awaited. Its just the very top level that is fire and forget. Its entirely possible (near impossible of likely) the Thread scheduler schedules the awaited threads exclusively and the program DOESNT exit before all the awaited things (main would just have to be paused for 4 seconds for this to happen). So thats the correction...there is still an await happening..now if there were no awaits anywhere youd be right
Yes exactly. There IS an await, the execution IS "awaited" in the sense that a context is being captured, etc.
But since the top level caller didn't "use" the await keyword, the execution would start but there would be no guarantee that we'd capture the full expected results.
PourWaterAsync() has indeed started, the inner awaits are functioning as they should, but we did not "wait" for the results and the program continues execution regardless.
I updated this section of the article, I hope I made it clearer this time. Really appreciate the feedback! ♥
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
i see what you were getting at now. i find the way it's worded to be confusing, but could be a me thing. that delay is definitely awaited, but the task doesn't happen to finish before the application exits. await can be used to mean both the beginning and end state of a task, but most commonly it refers to the beginning...you await a thing and the compiler builds up the continuation for you. Here you were referring to awaiting being the continuation after the result...this isn't a great way to think about it, cause it makes people think the execution is "blocked"
I think the confusion arises because we didn't have a consensus about the very idea of "awaiting".
I will try to rephrase the word "awaiting". If there is an await operator after an async method or its returned task, the compiler will store rest of code with its context and return a task (which will contain return value of rest of code in future) immediately to caller. The rest of the code will be executed only when that async method completes .
If there is no await operator after that async method, it is like fire and forgot. Rest of the code will be executed immediately without returning of async method.
I think Paula Fahmy is saying that. Any way async method will run (some thread will work there, doing // task delay(3000);// ) but caller of non awaiting async method will forgot about it and do next thing immediately.
Correct me if I am wrong
There are awaits in the nesting, so something is being awaited. Its just the very top level that is fire and forget. Its entirely possible (near impossible of likely) the Thread scheduler schedules the awaited threads exclusively and the program DOESNT exit before all the awaited things (main would just have to be paused for 4 seconds for this to happen). So thats the correction...there is still an await happening..now if there were no awaits anywhere youd be right
Yes exactly. There IS an await, the execution IS "awaited" in the sense that a context is being captured, etc.
But since the top level caller didn't "use" the await keyword, the execution would start but there would be no guarantee that we'd capture the full expected results.
PourWaterAsync() has indeed started, the inner awaits are functioning as they should, but we did not "wait" for the results and the program continues execution regardless.
I updated this section of the article, I hope I made it clearer this time. Really appreciate the feedback! ♥