3 ms·

This. And I hate doing this. I've talked myself out of the performance gains, because it just makes everything feel verbose and hard-to-read. I still wish they

• orf 10y ago
  I think that would be a big mistake to add a keyword. It apparently doesn't give much of a performance gain: https://stackoverflow.com/questions/13489065/best-practice-to-call-configureawait-for-all-server-side-code https://stackoverflow.com/questions/13489065/best-practice-t...
  • int_19h 10y ago
    It's not just about performance gain. The real problem is that if you don't ConfigureAwait(false), you don't know where your continuation is going to be executed, and how long it'll take to get there. Worse yet, posting to the original sync context increases potential for deadlocks. The UI thread often has to do something synchronously (e.g. invoke an API that doesn't have an async version), thereby blocking the event loop. If anywhere down the line it happens to wait on a task, and that task gets posted to the UI synchronization context, you have a deadlock. Note that the answer you link to is specifically for ASP.NET, where there's no UI thread. But for libraries, you don't know if they're going to be used in a web app or a GUI app. So, the safest thing is to always ConfigureAwait(false).