attende senza ConfigureAwait (false) continua su un thread diverso

Question

Ho un'app WinForms e ho del codice che deve essere eseguito sul thread dell'interfaccia utente. Tuttavia, il codice dopo lo await viene eseguito su un thread diverso.

protected override async void OnHandleCreated(EventArgs e) 
{ 
    base.OnHandleCreated(e); 

    // This runs on the UI thread. 
    mainContainer.Controls.Clear(); 

    var result = await DoSomethingAsync(); 

    // This also needs to run on the UI thread, but it does not. 
    // Instead it throws an exception: 
    // "Cross-thread operation not valid: Control 'mainContainer' accessed from a thread other than the thread it was created on" 
    mainContainer.Controls.Add(new Control()); 
} 

Ho anche provato ad aggiungere in modo esplicito ConfigureAwait(true), ma non fa differenza. La mia comprensione è stata che se ometto lo ConfigureAwait(false), la continuazione dovrebbe essere eseguita sul thread originale. È sbagliato in alcune situazioni?

Ho anche notato che se aggiungo un controllo alla raccolta prima dell'attesa, la continuazione viene eseguita magicamente sul thread corretto.

protected override async void OnHandleCreated(EventArgs e) 
{ 
    base.OnHandleCreated(e); 

    // This runs on the UI thread. 
    mainContainer.Controls.Add(new Control()); 
    mainContainer.Controls.Clear(); 

    var result = await DoSomethingAsync(); 

    // This also runs on the UI thread now. Why? 
    mainContainer.Controls.Add(new Control()); 
} 

La mia domanda è:

1. Perché succede questo?
2. Come convinco la continuazione per l'esecuzione sul thread dell'interfaccia utente (idealmente senza fare il mio hack di aggiungere un controllo e rimuoverlo)?

Per riferimento, ecco le parti importanti di DoSomethingAsync. Invia una richiesta HTTP usando RestSharp.

protected async Task DoSomethingAsync() 
{ 
    IRestRequest request = CreateRestRequest(); 

    // Here I await the response from RestSharp. 
    // Client is an IRestClient instance. 
    // I have tried removing the ConfigureAwait(false) part, but it makes no difference. 
    var response = await Client.ExecuteTaskAsync(request).ConfigureAwait(false); 

    if (response.ResponseStatus == ResponseStatus.Error) 
     throw new Exception(response.ErrorMessage ?? "The request did not complete successfully."); 

    if (response.StatusCode >= HttpStatusCode.BadRequest) 
     throw new Exception("Server responded with an error: " + response.StatusCode); 

    // I also do some processing of the response here; omitted for brevity. 
    // There are no more awaits. 
} 

Answer 1

Sembra che qualcosa di strano sta accadendo con OnHandleCreated. La mia soluzione era usare OnLoad invece. Sono abbastanza contento di questa soluzione perché non c'è davvero alcun motivo per utilizzare OnHandleCreated nella mia situazione.

Sono ancora curioso di sapere perché questo sta accadendo, quindi se qualcuno lo sa, sentitevi liberi di inviare un'altra risposta.

Edit:

ho trovato il vero problema: si scopre che mi stava chiamando Form.ShowDialog() dopo un ConfigureAwait(false). In quanto tale, il modulo veniva costruito sul thread dell'interfaccia utente, ma in quel momento stavo chiamando ShowDialog su un thread non dell'interfaccia utente. Sono sorpreso che questo ha funzionato a tutti.

Ho rimosso il ConfigureAwait(false) così ora ShowDialog viene chiamato sul thread dell'interfaccia utente.

Answer 2

La mia comprensione era che se ometto ConfigureAwait (false), la continuazione dovrebbe essere eseguita sul thread originale. È sbagliato in alcune situazioni?

Cosa succede in realtà è che await catturerà l'attuale contesto di default, e utilizzare questo contesto, per riprendere il metodo async. Questo contesto è SynchronizationContext.Current, a meno che non sia null, nel qual caso è TaskScheduler.Current (in genere il contesto del pool di thread). Il più delle volte, il thread dell'interfaccia utente ha un'interfaccia utente SynchronizationContext - nel caso di WinForms, un'istanza di WinFormsSynchronizationContext.

Ho anche notato che se aggiungo un controllo alla raccolta prima dell'attesa, la continuazione viene eseguita magicamente sul thread corretto.

Nessun thread inizia automaticamente con un SynchronizationContext. WinForms SynchronizationContext viene installato su richiesta al momento della creazione del primo controllo. Questo è il motivo per cui lo vedi riprendere su un thread dell'interfaccia utente dopo aver creato un controllo.

Poiché il passaggio a OnLoad è una soluzione praticabile, vi consiglio di andare con quello. L'unica altra opzione (per riprendere il thread dell'interfaccia utente prima della creazione di un controllo) consiste nel creare manualmente un controllo prima del primo await.