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
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Claudiu Codoban shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      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