È vantaggioso utilizzare ConfigureAwait (false) in una libreria che restituisce direttamente un'attività da una chiamata a un'altra libreria?

Question

Follow-up a this question. Ho una libreria con molti metodi asincroni che avvolgono sottilmente HttpClient. Effettivamente hanno solo fare un po 'di installazione e tornare direttamente il Task restituita dalla chiamata HttpClient:

public Task DoThingAsyc() { 
    // do some setup 
    return httpClient.DoThingAsync(); 
} 

sto meditando se aggiungere ConfigureAwait(false) a queste chiamate. La saggezza prevalente sembra essere "sì, fallo sempre nelle biblioteche". Ma in questo caso, introdurrebbe un overhead (forse trascurabile), perché ConfigureAwait restituisce uno ConfiguredTaskAwaitable che dovrebbe essere ricollocato in un Task per non modificare la firma del metodo. Certamente non è difficile codice:

public async Task DoThingAsyc() { 
    // do some setup 
    return await httpClient.DoThingAsync().ConfigureAwait(false); 
} 

La mia domanda è, sarà i benefici di efficienza di ConfigureAwait(false) probabile superare il sovraccarico introdotto in questo caso? Quale esempio sopra sarebbe considerato la pratica migliore?

Answer 1

No, non farlo.

Poiché non si utilizza await, non è necessario configurarlo in anticipo. È responsabilità del chiamante della tua biblioteca effettuare la chiamata ConfigureAwait. E il chiamante potrebbe voler chiamare ConfigureAwait(true) invece di ConfigureAwait(false) - non lo sai.

Chiamare ConfigureAwait(false) nel codice libreria è consigliabile solo quando si attendono su di esso nella libreria.

Nella maggior parte dei casi, il codice come questo:

Task<Something> DoSomethingAsync() 
{ 
    return await DoSomethingElseAsync().ConfigureAwait(false); 
} 

è equivalente a:

Task<Something> DoSomethingAsync() 
{ 
    return DoSomethingElseAsync(); 
} 

seDoSomethingElseAsync rispetta il contratto Task (per esempio, se si restituisce un failed Task invece di generare eccezioni).

La creazione di una macchina di stato aggiuntiva per questo è solo l'aggiunta di uno strato di codice di avvolgimento senza valore aggiunto: è preferibile semplicemente restituire direttamente lo Task.

In altre parole: si ottiene nessun vantaggio di efficienza di qualsiasi tipo,, al contrario.

Answer 2

No, ConfigureAwait come suggerisce il nome, configura lo await. Se non è necessario await, non è necessario configurarlo.

Non c'è alcun valore aggiunto nell'aggiunta di asincrono-attendi solo per utilizzare ConfigureAwait in quanto influisce solo sul metodo e non sul metodo di chiamata. Se il chiamante deve usare ConfigureAwait lo faranno da soli.

Avere un metodo asincrono invece di un semplice metodo Task -returning è una scelta valida per molte ragioni (ad es.gestione delle eccezioni) e richiederà l'utilizzo di ConfigureAwait ma ConfigureAwait non è un buon motivo per farlo da solo.