Come impostare TaskContinuationOptions utilizzando async/await?

Posso avere tutte le opzioni come OnlyOnRanToCompletion, OnlyOnCanceled, NotOnFaulted, ecc. Usando async/await? Non riesco a trovare esempi su come ottenere gli stessi risultati come utilizzare le attività, per esempio:Come impostare TaskContinuationOptions utilizzando async/await?

Task.Factory.StartNew(foo).ContinueWith(bar, TaskContinuationOptions.NotOnRanToCompletion);

io non sono sicuro se semplice gestione condizionale o eccezione in grado di gestire tutti i comportamenti di continuazione disponibili in Attività esplicite.

fonte

2013-10-22 natenho

È possibile impostare i flag dei bit? Dovresti essere capace di. Tbh, non sono sicuro di cosa stai chiedendo –

Per la gestione delle eccezioni non è necessario; usa solo un blocco 'try/catch' e puoi scrivere un codice come se lo scrivessi come faresti in qualsiasi codice virtualmente da qualsiasi altra parte. Perché dovresti * volere * usare invece quello stile? Se vuoi usare qualcosa di diverso dalle opzioni "OnlyOn *" o "NotOn *", di quale hai bisogno e perché? – Servy

@natenho, se proprio ne hai bisogno, dovresti essere in grado di implementare questo comportamento con un [custom awaiter] (http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx). – Noseratio

Posso avere tutte le opzioni come OnlyOnRanToCompletion, OnlyOnCanceled, NotOnFaulted, ecc. Usando async/await?

Non è necessario.

Invece di sintassi copiosa utilizzando flag di bit e continuazioni lambda, await supporta una molto naturale try/catch sintassi:

try 
{ 
    await foo(); 
} 
catch 
{ 
    bar(); 
    throw; 
}

io non sono sicuro se semplice gestione condizionale o eccezione in grado di gestire tutta la continuazione comportamenti disponibili in Attività esplicite.

Naturalmente essi gestiscono None, NotOnCanceled, NotOnFaulted, NotOnRanToCompletion, OnlyOnCanceled, OnlyOnFaulted e OnlyOnRanToCompletion. La maggior parte delle altre flag ha senso solo per le attività parallele, non per le attività asincrone. Ad esempio, AttachedToParent, HideScheduler e PreferFairness non hanno senso nel mondo async; DenyChildAttach, LazyCancellation e ExecuteSynchronously devono essere sempre essere specificato nel mondo async; e LongRunningmai dovrebbe essere.

fonte

2013-10-22 21:40:40

La semplice gestione delle eccezioni è stato il mio primo approccio per NotOn * ed è buono per confermare che va bene.Dovrò dare un'occhiata più da vicino alle altre flag per rivedere l'ultima parte della frase;) – natenho

Sono arrivato qui quando mi sono imbattuto in una situazione che dovevo specificare il flag "HideScheduler" , e non potevo . Lo scenario: un metodo asincrono è chiamato da un thread GUI , il cui thread GUI è bloccato fino alla fine della chiamata asincrona. Ciò provoca un deadlock perché la continuazione viene registrata nel thread GUI (in attesa e bloccato). HideScheduler salverebbe il giorno. Work-around: 'Nuova attività ({chiamata asincrona}, TaskCreationOptions.HideScheduler) .Start()' e attendere questa attività temporanea. – robert4

So che di solito è un disegno malato che il thread della GUI sia bloccato durante una chiamata asincrona, ma questo era un programma speciale: principalmente operazioni headless (immagina un'attività di backup) con GUI usata durante lo sviluppo solo per fornire feedback - invisibile/disabilitato/bloccato nell'ambiente di produzione. – robert4

Non credo.

Async/await non è stato creato per sostituire TPL tutti insieme, ma per completarlo semplificando le operazioni.
Se è ancora necessaria una configurazione aggiuntiva, è necessario attenersi alle attività oppure provare a implementare un utente di attesa personalizzato con questo comportamento.

fonte

2013-10-22 21:40:27

Come impostare TaskContinuationOptions utilizzando async/await?

risposta

Problemi correlati