I suggest you ...

ConfigureAwait(false) by default

When you don't need to have full control over your thread pool context while using the async/await pattern, it is recommended that we always use ConfigureAwait(false) for various reasons (see article: https://msdn.microsoft.com/en-us/magazine/jj991977.aspx).

I find that the cases when you need control over the context are very rare.

I want to suggest that ConfigureAwait(false) is used by default when doing async/await to simplify the coding process.

18 votes
Vote
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Claudiu Codoban shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

3 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • Patrick Morris (Telavian) commented  ·   ·  Flag as inappropriate

    I am frankly not sure why the runtime can't figure this out automatically. I learned this the hard way.

    I tried using a common library in ASP.Net and have major deadlocks. Therefore I am literally going through about 1500 places and adding this. Very tedious.

    When I need the context then I can opt-in. However rarely do we really care which thread a task runs on.

  • Matt Kerr commented  ·   ·  Flag as inappropriate

    I agree that it should just automatically do the right thing but ASP.NET needs context preserved for retaining the exception stack when throws occur, even in async/await, or else you will lose it. Another example is calling common code from a constructor in an Actor in Project Orleans, vs calling it from a Grain- using the wrong context can cause difficult to diagnose problems since you can lose the error messages or Grain thread continuation.

Feedback and Knowledge Base