Hat jemand ein Szenario für die Verwendung von ConfigureAwait(true) gefunden? Da true die Standardoption ist, die ich nicht sehen kann, wann würdest du sie jemals benutzen?
Eine Möglichkeit, die ich sehen kann, ist, wenn Sie Code in einer Bibliothek schreiben und Ihren Anrufern erlauben zu entscheiden, ob es angemessen ist, den ursprünglichen Kontext 1 fortzusetzen (obwohl ich normalerweise argumentieren dafür, niemals den ursprünglichen Kontext innerhalb des Bibliothekscodes fortzusetzen)
Ihr Aufrufer übergibt entweder einen bool -Parameter oder legt einen Konfigurationswert fest, sodass Sie bis zur Laufzeit nicht wissen, was der korrekte Argumentwert ist.
Dies ist der allgemeine Antworttyp für APIs wie diese, die eine No-Args-Variante und eine Variante mit einem einzigen Argument haben, wobei die No-Args-Variante als "dasselbe wie die Single-Argument-Variante mit Bekannter Wert x "- Wenn Sie bis zur Laufzeit nicht wissen, welcher Wert übergeben werden soll, sollten Sie einfach die Argumentvariante mit dem korrekten Laufzeitwert aufrufen.
1 z. Ihr Anrufer liefert auch einen Delegierten. Ihr Anrufer wird wissen (und kann entscheiden), ob dieser Delegat wieder im ursprünglichen Kontext sein muss oder nicht.
true, um zu versuchen, die Fortsetzung in den ursprünglichen Kontext zurückzuversetzen; sonst, falsch.
Es ist eigentlich eher so, dass wir sagen, dass ConfigureAwait(true) mit .ContinueWith( t => {...}, TaskScheduler.FromCurrentSynchronizationContext()) vergleichbar ist, wobei ConfigureAwait(false) mit .ContinueWith( t => {...}) vergleichbar ist. Wenn Sie false übergeben, kann die Fortsetzung in einem Threadpool-Thread ausgeführt werden, anstatt zum aktuellen Synchronisationskontext zurückzukehren.
Da true die Standardoption ist, die ich nicht sehen kann, wann würdest du sie jemals benutzen?
Ein naheliegender Anwendungsfall ist, wenn Sie sicherstellen wollen, dass jedes Mal, wenn etwas erwartet wird, eine explizite und bewusste Entscheidung darüber getroffen wird, was mit dem Synchronisationskontext zu tun ist.
Beispiel-Richtlinie von Ссылка :
Bei NML bevorzugen wir immer explizit anzugeben, wie wir die Aufgabe haben wollen Fortsetzung zu erfolgen. Auch wenn der Standard einer Aufgabe ist ConfigureAwait (true), wir spezifizieren es immer noch so, dass wir es sind immer bewusst, was "unter der Haube" passiert.
Um die Lesbarkeit zu verbessern, verwenden sie eine Erweiterung anstelle von ConfigureAwait(true) direkt:
Wenn Sie jedoch viel Code betrachten, einige mit ConfigureAwait (true) und einige mit ConfigureAwait (false), ist es nicht leicht zu erkennen, wo sie sich unterscheiden. Also benutzen wir beides ConfigureAwait (false) oder eine nützliche Erweiterungsmethode, ContinueOnCapturedContext (). Es macht das Gleiche, aber nur unterscheidet es auf visuellere Weise von ConfigureAwait (false).
Tags und Links c# asynchronous