1

This has always been a good practice to use ConfigureAwait(false) whenever an async call is made. Then ASP.NET Core came and it uses thread pool context instead of thread context and this became irrelevant. My understanding is that this is nothing to do with the fact it's .NET Core, rather a new implementation of ASP.NET managed to improve things and as a result we don't need to write this annoying ConfigureAwait(false) any more. I didn't find any meaningful answer on whether I still need to use ConfigureAwait(false) if I know that my code will only be hosted by a Service Fabric service and if this answer is any different if it's hosted on Stateful/Stateless service, implemented in .NET Framework or .NET Core, uses Azure Service Bus handlers or NServiceBus handlers that may rely on SynchronizationCntext.

Does Service Fabric use SynchronizationContext and is it ok to ditch ConfigureAwait(false) when code is hosted only in Service Fabric?

root
  • 2,327
  • 1
  • 22
  • 18
  • "good practice to use `ConfigureAwait(false)`" - that's very controversial statement... https://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code?rq=1 – Alexei Levenkov Oct 14 '19 at 22:53
  • @AlexeiLevenkov in that answer and the linked blog it says [in ASP.NET Core] _You Don’t Need ConfigureAwait(false), But Still Use It in Libraries_. In other words it **only** says drop it in `ASP.NET Core` and still use it everywhere else. My question is - where else can I stop doing it. – root Oct 15 '19 at 07:49
  • 1
    It was always a bad idea to use `ConfigureAwait(false)` everywhere without thinking about it. It can cause bugs that would be hard to find unless you know what it's doing (like `HttpContext` suddenly being null after an awaited async call). The only place it should be used as a rule is in libraries. It only solves problems with deadlocks when making blocking calls to async methods, and a library doesn't know how the methods will be called. – Gabriel Luci Oct 15 '19 at 12:26
  • It is possible @GabrielLuci, however the mentioned answer, the linked blog, and many MSDN articles say otherwise - if you don't need to access thread context (UI applications, `ASP.NET` etc.) it **is** a good idea. – root Oct 15 '19 at 21:55
  • Right - *"if"*. That's what I mean. I've seen people always use `ConfigureAwait(false)` everywhere without understanding what it does. That's asking for trouble. – Gabriel Luci Oct 15 '19 at 22:34
  • But if you're really worried about performance, maybe you can try doing some benchmarks. You might be surprised at how little it matters. Personally, I never use `ConfigureAwait(false)` unless I need to avoid a deadlock. – Gabriel Luci Oct 15 '19 at 22:35
  • @GabrielLuci, you're right, benchmark is a good way but it's application specific. My question is about _spherical cow in a vacuum_ coding practices. And avoiding deadlocks with `ConfigureAwait` has its strong opponents: [Using ConfigureAwait(false) to avoid deadlocks is a dangerous practice ... is at best just a hack](https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html) – root Oct 16 '19 at 19:42
  • @root Yes, I've read that before. Ideally you should not block on async code at all. "Use async all the way down". Then you don't need `ConfigureAwait(false)` anywhere. That's kind of my point. You don't need it. – Gabriel Luci Oct 16 '19 at 19:48

0 Answers0