Dotnet-api-docs: explain default behavior of ConfigureAwait()

Created on 3 Jun 2018  Â·  9Comments  Â·  Source: dotnet/dotnet-api-docs

what is the default behavior? will code continue to run on captured context by default or not?
> ...attempt to marshal...

Does that mean attempt may fail? Under what conditions?


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

.neprod Not Triaged Pri2 area-System.Threading.Tasks

Most helpful comment

This topic definitely should be documented much better, or at least pointed out to another pages where the method would be explained more thoroughly.

All 9 comments

@stephentoub can you help with this issue?

what is the default behavior? will code continue to run on captured context by default or not?

When await'ing a Task/Task<T>, the default behavior is the same as if .ConfigureAwait(continueOnCapturedContext:true) was used. That means that the awaiter looks to see if there's a non-default SynchronizationContext (or if there isn't, a non-default TaskScheduler) present, and if there is, it stores it for the continuation to be handed off to when the awaiter completes.

...attempt to marshal...

That means there may not be anything to marshal back to... there may not be a context to capture, e.g. SynchronizationContext.Current may return null.

I think it is interesting that here the true case is documented but when devs use it they pass false which is not documented what that means. Since this affects how the continuation is invoked which is important to understand when it comes to avoid dead-locks and/or race conditions I think this methods should be one of the most documented methods in .NET API. Also the name is not helping I think.

This topic definitely should be documented much better, or at least pointed out to another pages where the method would be explained more thoroughly.

Yes, better documentation for this would be very appreciated! :)

And please provide good example codes.

This is a method that is hard for the community to help document because TBH the details of how async really works is poorly understood and when it comes to concurrency the details matters.

Why is the default value set to true and FxCop tells you to use false? Is it true that this doesn't apply to .Net Core?

Please document that the bool continueOnCapturedContext parameter controls only SynchronizationContext and not ExecutionContext. In particular, if you set AsyncLocal\.Value before awaiting and get it afterwards, then you will find the same value, regardless of whether continueOnCapturedContext is true or false.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mairaw picture mairaw  Â·  6Comments

gewarren picture gewarren  Â·  4Comments

FierceLlama picture FierceLlama  Â·  3Comments

ygoe picture ygoe  Â·  4Comments

jfranki picture jfranki  Â·  5Comments