You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It just adds the necessary logic to allow releasing the current thread, and marshal the result back on that same thread [...]
This depends on the current SynchronizationContext and/or TaskScheduler (default one for GUI thread resumes on same context) and whether ConfigureAwait() was specified or not.
In other words, use async only for I/O bound operations.
It seems too restricitve. There are other scenarios where async/await might make sense. For example to make a UI responsive. Additionally, much like the IDisposable patter, async/await is a kind of "contaminating" pattern and when you start using it you often have to go all the way and make other methods async as well, avoiding the smelly async void case.
The text was updated successfully, but these errors were encountered:
This depends on the current SynchronizationContext and/or TaskScheduler (default one for GUI thread resumes on same context) and whether ConfigureAwait() was specified or not.
You're right. We need to rephrase that.
For example to make a UI responsive.
If it involves an I/O intensive operation, then yes. But if it's CPU bound, you'll need to queue a task using the Task.Run, right?
This depends on the current SynchronizationContext and/or TaskScheduler (default one for GUI thread resumes on same context) and whether
ConfigureAwait()
was specified or not.It seems too restricitve. There are other scenarios where async/await might make sense. For example to make a UI responsive. Additionally, much like the IDisposable patter, async/await is a kind of "contaminating" pattern and when you start using it you often have to go all the way and make other methods
async
as well, avoiding the smellyasync void
case.The text was updated successfully, but these errors were encountered: