Kann ich ConfigureAwait (false) in SignalR-Hubs verwenden, oder stützt sich die SignalR-Infrastruktur auf SynchronizationContext?

Question

Ich habe einige Hub-Methoden, die E/A-Operationen ausführen, die ich asynchron aufrufen möchte.

Ist es sicher, ConfigureAwait(false) in meinen Hub-Methoden zu verwenden, oder benötigt SignalR einen erfassten SynchronizationContext für Anforderungsinformationen oder etwas ähnliches?

public async Task<Response> Save() { 
     // do some prep work 
     var response = await SaveThingsAsync().ConfigureAwait(false); 
     // do something with response 
     return response; 
    } 

Zur Klarstellung: mein Code Thread Kultur oder irgendetwas anderes in der SynchronizationContext nicht gespeichert erfordern.
Meine Sorge ist, dass der SignalR-Server-Code dort Informationen speichern kann, wie Client-IDs, Anfrage-Infos oder ähnliches, auf die er möglicherweise nicht zugreifen kann, wenn die Async-Methode von einem anderen Thread fortgesetzt wird.

Als ich meine Methode testete, schien es gut zu funktionieren, aber das beweist nichts unbedingt.

Answer 1

SignalR hängt nicht von SynchronizationContext ab. Es wird häufig in Win32-Diensten (und Konsolen-Apps zum Testen) selbst gehostet, wo es keine SynchronizationContext gibt.

Siehe auch this SignalR issue.

Answer 2

ConfigureAwait entfernt den Synchronisierungskontext nicht. Es bewirkt lediglich, dass die Taskvervollständigungsfortsetzung den aktuellen Sync-Kontext nicht verwendet.

Es ist immer sicher zu verwenden, wenn der Rest der aktuellen asynchronen Methode nicht vom Synchronisierungskontext abhängt. Hervorhebung an Methode im Gegensatz zu Thread.