ConfigureAwait (false) pertinent dans ASP.NET Core?

101

Je suis tombé sur un problème ( https://github.com/HTBox/allReady/issues/1313 ) sur GitHub où ils ont discuté de la ConfigureAwait(false)suppression du code, affirmant que, dans ASP.NET Core

l'appel à ConfigureAwait(false)est redondant et ne fait rien

Le mieux que je puisse trouver ici est une «note d'accompagnement» dans une réponse (de Stephen Cleary, https://stackoverflow.com/a/40220190/2805831 ) disant que

ASP.NET Core n'a plus de «contexte»

Donc, est-ce ConfigureAwait(false)vraiment inutile dans ASP.NET Core (même si vous utilisez .Net Framework complet)? At-il un réel gain de performances dans certains cas ou une différence de résultat / sémantique?

EDIT: Est-ce différent dans cet aspect si je l'héberge en tant qu'application console ou dans IIS?

.net asp.net-core async-await

— Pedro Lorentz
source

Cela dépend de l'endroit où vous prévoyiez de l'utiliser. Si vous vouliez l'utiliser directement dans votre application ASP.NET Core, alors non, vous n'avez pas à l'appeler (vous n'avez pas eu à l'appeler dans l'héritage ASP.NET ni dans iirc). Mais si vous écrivez une bibliothèque, vous devez toujours l'utiliser ConfigureAwait(false), car la bibliothèque peut être consommée par différentes applications (ASP.NET Core, WPF, UWP, Console, etc.)

— Tseng

ASP.NET Core s'exécute en tant qu'application console par défaut et les applications console AFAIK n'ont pas de SynchronizationContext, donc oui, cela semble raisonnable pour une application ASP.NET Core par défaut, même avec le Framework complet.

— Joe White

@JoeWhite Ok, a édité la question. Est-ce différent si mon application ASP.NET Core est dans IIS?

— Pedro Lorentz

Une application ASP.NET Core exécutée dans IIS s'exécute toujours en tant qu'application console - la seule différence est qu'IIS démarre et arrête des instances de votre application (de la même manière qu'il aurait géré des instances du processus de travail ASP.NET dans ASP.NET classique). Cela ne changerait aucun comportement lié aux threads dans votre application ASP.NET. (La seule raison pour laquelle j'ai spécifié « par défaut » est que vous pouvez, par exemple, l' hôte ASP.NET de base dans une application GUI, et dans ce cas , vous auriez devoir penser le contexte de synchronisation.)

— Joe White

Remarque ConfigureAwait(false), bien que pertinent dans ASP.NET classique, n'est en aucun cas nécessaire . C'est un compromis: cela atténue en quelque sorte certains blocages de synchronisation sur asynchrone (qui sont de toute façon des défauts de conception - ils n'existent pas à moins que quelqu'un ne fasse quelque chose de stupide) et augmente parfois les performances de ~ microseconde en ne rechargeant pas le contexte. Au prix de ne pas pouvoir dépendre du contexte, et d'avoir ConfigureAwaittout à travers votre code. stackoverflow.com/questions/28221508/…

— Dax Fohl

Réponses:

106

ConfigureAwaita uniquement des effets sur le code exécuté dans le contexte d'un SynchronizationContextdont ASP.NET Core n'a pas (ASP.NET "Legacy" le fait).

Le code à usage général doit toujours l'utiliser car il peut être exécuté avec un fichier SynchronizationContext.

SynchronizationContext ASP.NET Core

— Paulo Morgado
source

Je veux juste mettre une légère clarification, ASP.NET dans un environnement non principal a un contexte de synchronisation, mais pas ASP.NET core.

— Scott Chamberlain

@Morgado, est-ce vrai même si l'application est hébergée dans IIS?

— Pedro Lorentz

Une application ASP.NET Core n'est pas hébergée dans IIS. IIS agit simplement comme un proxy inverse.

— Paulo Morgado

J'ai mis à jour la réponse avec un article récent de Stephen Cleary. Mais oui, ASP.NET Core est ASP.NET Core.

— Paulo Morgado

@NamNgo. J'apprécie qu'il s'agit d'un ancien message maintenant, mais Stephen Cleary clarifie cela dans l'une des questions sur le message que Paulo a lié ci-dessus. "c'est le framework (ASP.NET Core par opposition à ASP.NET Classic) qui détermine le SynchronizationContext, pas le runtime (.NET Core par opposition à .NET 4.6.2)"

— Gavin Sutherland

Et ça?

En ce moment (février-2020), les développeurs sur MS Blog recommandent d'utiliser ConfigureAwait (false) afin d'améliorer les performances, d'éviter les blocages. https://devblogs.microsoft.com/dotnet/configureawait-faq/

J'ai entendu dire que ConfigureAwait (false) n'est plus nécessaire dans .NET Core. Vrai? Faux. Il est nécessaire lors de l'exécution sur .NET Core pour exactement les mêmes raisons que pour l'exécution sur .NET Framework. Rien n'a changé à cet égard.

— Alfred Severo
source

Si un code utilisateur (ou un autre code de bibliothèque utilisé par votre application) définit un contexte personnalisé et appelle votre code, ou appelle votre code dans une tâche planifiée sur un TaskScheduler personnalisé, alors même dans ASP.NET Core, vos attentes peuvent voir un non- contexte ou planificateur par défaut qui vous conduirait à vouloir utiliser ConfigureAwait (false). Bien sûr, dans de telles situations, si vous évitez le blocage synchrone (ce que vous devriez éviter de faire dans les applications Web de toute façon) et si vous ne vous souciez pas des faibles coûts de performance dans des occurrences aussi limitées, vous pouvez probablement vous en sortir sans utiliser ConfigureAwait (false) .

— Alisson le

Selon cela, je dirais que dans la plupart des cas, ce n'est pas nécessaire. Sauf si vous utilisez un contexte de synchronisation personnalisé ou une bibliothèque qui le fait.

— Alisson le