When/how should we use ConfigureAwait(false) throughout the Reqnroll code

[gasparnagy]

I have extracted this discussion from PR #223 involving @clrudolphi @obligaron @304NotModified.

Basically there we said that https://learn.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca2007 suggests "Passing false is a good option for app-independent libraries."

We use waits throughout the code base heavily, so we should have an agreement when/how we should use ConfigureAwait(false).

[gasparnagy]

My notes to that discussion:

Statements to consider

• We mostly need async awaits, because we want to provide the async environment users code, so that they can call real async calls
• We have only a few cases when we invoke real async calls directly (e.g. writing to files with Cucumber Messages)
• In some situations (especially Cucumber Messages) we use background processing, where we don't want to lock a thread, so we implemented it async
• We are running in the async environment of the test frameworks (that is the "app" in our case)

My immediate thoughs on this:

So in my opinion when we consider calling ConfigureAwait(false) we should distinguish, between the cases:

1. we do the async call because we need to call the user code async (in this case we should not configure the async behavior because essentially we will then change the testing behavior. If the user needs, they can call ConfigureAwait(false) for their own code
2. we need the asynchrony ourselves, but running as a background process anyway: ConfigureAwait(false) has no effect, so not needed
3. we need the asynchrony ourselves, but integrated into the test execution: here ConfigureAwait(false) might be necessary and we have to be anyway very careful with these, so would be good to have a list before we blindly apply ConfigureAwait(false)

[Code-Grump]

Ok, this is a really bad bit of advice to follow; it's one of the areas of async/await I feel most strongly about, because Microsoft's advice is lacking nuance.

ConfigureAwait(false) says "I do not care about the context in which any potential continuations may run". The advice to use this everywhere in libraries is broadly sensible: libraries that perform a utility function generally shouldn't care about their execution context.

Where this falls apart is that you need to be really sure you never touch objects that might be sensitive to execution context. For example, if you're accessing something that is associated with the current thread, your code can only work when continuations are scheduled back to that thread. This presents a problem, because this API is largely invisible: you don't know if context matters until it causes a problem.

And the benefits of ConfigureAwait(false) are pretty minimal. You can get some better performance by allowing work to be scheduled to more general thread pool threads, and you might avoid deadlocks caused by some bad code performing a synchronous wait on a task (something nobody should be doing.) The costs of doing this are that every time we await we have to insert some extra boilerplate. It's not a big cost, but it's definitely arduous.

The ASP.NET team stopped adding ConfigureAwait(false) to their library code a while ago. The benefits aren't worth the cost there - all their code is intended to run in context-free hosts, so they're running without synchronisation by default. Adding additional code to gain small benefits in edge cases is not a good model for development.

[304NotModified]

First of all, I really dislike the syntax of ConfigureAwait(false). Luckily we dont need it anymore in ASP.NET Core and I'm really happy with that.

But Reqnroll also supports (of course) .NET framework and then I think it's a good idea to use ConfigureAwait(false), as advised by MS. Mostly because of the deadlock prevention.

About point 2, is that also true for .NET framework?

About point 1,

If the user needs, they can call ConfigureAwait(false) for their own code

I'm not sure if this correct. ConfigureAwait(true) is the default and if you don't need the synchronization, you need ConfigureAwait(false) on all awaits. But correct me if wrong!

[Code-Grump]

To help clarify:

ConfigureAwait(...) controls what task scheduling will be used for any continuations from that await location. The default is to run the continuation in the context that was present up to the await point.

That means where the code is executing determines the default. If your method is executing on a thread pool thread, the continuation is going to run on a thread pool thread. Likewise if the method is on the Windows UI thread, the continuation is scheduled back to that thread. If our methods all have a ConfigureAwait(false) in them, they will ignore the context and schedule their continuations to the default scheduler.

Any user calling our methods still has full control over their continuations - you can only control your own continuations.