Perché è necessario AsyncContext quando si utilizza async/await con un'applicazione console?

Question

Sto chiamando un metodo asincrono all'interno della mia applicazione console. Non voglio che l'app si interrompa poco dopo il suo avvio, cioè prima che vengano completate le attività attendibili. Sembra che io possa fare questo:

internal static void Main(string[] args) 
{ 
    try 
    { 
     Task.WaitAll(DoThisAsync()); 
    } 
    catch (Exception ex) 
    { 
     Console.Error.WriteLine(ex); 
     throw; 
    } 
} 

internal static async Task DoThisAsync() 
{ 
    //... 
} 

Ma secondo Stephen Cleary's article sembra che non posso fare questo e invece creare una sorta di contesto per l'asincrona per tornare quando è fatto (per esempio AsyncContext).

Il codice sopra funziona, tuttavia, e restituisce il thread principale dopo Task.WaitAll(DoThisAsync());, quindi perché è necessario utilizzare un contesto personalizzato?

Answer 1

Non richiesto; è solo la mia preferenza

Puoi sincrono bloccare su un compito all'interno Main (usando Wait/Result/WaitAll). La semantica è leggermente diversa; in particolare, se il codice asincrono fallisce, allora/avvolgerà l'eccezione in uno AggregateException, mentre lo AsyncContext no.

Inoltre, AsyncContext tratta specificamente il filo principale; invece di inviare continuazioni al pool di thread, le invierà di nuovo al thread principale (per impostazione predefinita, è sempre possibile utilizzare ConfigureAwait(false) per evitare ciò). Lo trovo utile se sto scrivendo un'app console "proof of concept", perché AsyncContext si comporta in modo molto simile ai contesti dell'interfaccia utente.

Ma alla fine, è solo una questione di preferenza.