Remove WithCurrentCulture (Resolves #862)

[bricelam]

No description provided.

[divega]

Don't we still need to chain ConfigureAwait(false) to each async call to avoid dealocks in UI apps?

If that was the case, I would suggest we went with a different approach which is to "#ifdef" the unnecessary code from WithCurrentCulture() out on specific platforms. We could then talk about renaming WithCurrentCulture() to something else, e.g. MakeThisAsyncCallWork() 😄

[bricelam]

Ah, I missed that part. 😄 This was just a desperate effort to try and get the tests passing on my machine. It didn't work. I'll leave the work for later since it's marked as pri1.

[bricelam]

Re-openeing. Confirmed with @AndriySvyryd that ConfigureAwait isn't really needed on modern platforms.

[bricelam]

P.S. If we do end up bringing this back. I propose we call it .MakeItSo()

[divega]

👍 at .MakeItSo() 😄

[AndriySvyryd]

[StephenCleary]

Confirmed with @AndriySvyryd that ConfigureAwait isn't really needed on modern platforms.

Not sure what this means. ConfigureAwait is beneficial in all UI contexts, including modern ones.

[AndriySvyryd]

@StephenCleary This is referring to modern platforms having async entry points/callbacks. And that as long as async methods are only invoked from other async methods ConfigureAwait(false) is not needed to prevent deadlocks.

[StephenCleary]

That's only one purpose of ConfigureAwait(false).

ConfigureAwait(false) documents the code as not needing a context. Also, it is more efficient (when a context is present) - in particular, it prevents performance death by a thousand paper cuts.

And there are still scenarios where sync-over-async is necessary, and there likely will always be (think third-party library extension points / callbacks that are synchronous). ConfigureAwait(false) is still necessary to prevent deadlock in those scenarios.

[AndriySvyryd]

@StephenCleary We handle those scenarios by offering a sync version of every method. Sync is faster than async even with ConfigureAwait(false) and it doesn't have any deadlock potential.

ConfigureAwait(false) litters the code, it's easy to forget to use it and could cause nonobvious issues where a series of library calls ends up invoking user code that does need context.

[StephenCleary]

Yes, the synchronous versions handle the synchronous scenarios.

There's still the "paper cuts" issue - by that I mean that the general guidance is to not have more than a hundred continuations per second on a UI thread. This can be reached pretty quickly if there's deeply-nested async calls all of which resume on the context.

But it's pretty rare, and probably not worth the clutter that ConfigureAwait(false) would cause; if a user does run into that performance issue, they can call the asynchronous EF APIs outside of a UI context.