Wie TaskContinuationOptions mit async/await?

Kann ich alle Optionen wie OnlyOnRanToCompletion, OnlyOnCanceled, NotOnFaulted usw. mit async/have? Ich kann keine Beispiele auf, wie man die gleichen Ergebnisse zu erzielen wie Aufgaben verwenden, zum Beispiel:Wie TaskContinuationOptions mit async/await?

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

Ich bin mir nicht sicher, ob einfache bedingte oder Ausnahmebehandlung all Fortsetzungsverhalten in expliziten Aufgaben verwalten kann.

Quelle

2013-10-22 natenho

Können Sie die Bitflags setzen? Du solltest dazu fähig sein. Tbh, nicht sicher, was Sie fragen –

Für die Ausnahmebehandlung wird es nicht benötigt; Verwenden Sie einfach einen 'try/catch'-Block und Sie können Code schreiben, so wie Sie ihn schreiben, wie Sie es in jedem anderen Code tun würden. Warum würdest du * diesen * stattdessen benutzen wollen? Wenn Sie etwas anderes als die Optionen "OnlyOn *" oder "NotOn *" verwenden möchten, welche benötigen Sie und warum? – Servy

@natenho, wenn Sie es wirklich brauchen, sollten Sie in der Lage sein, dieses Verhalten mit einem [custom warer] (http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx) zu implementieren). – Noseratio

Kann ich alle Optionen wie OnlyOnRanToCompletion, OnlyOnCanceled, NotOnFaulted usw. mit async/have?

Sie müssen nicht.

Statt reichlich Syntax Bitflags und Lambda-Fortsetzungen mit, await unterstützt eine sehr natürliche try/catch Syntax:

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

Ich bin nicht sicher, ob einfache bedingte oder Ausnahmebehandlung alle die Fortsetzung verwalten Verhalten, die in expliziten Aufgaben verfügbar sind.

Sie kümmern sich natürlich None, NotOnCanceled, NotOnFaulted, NotOnRanToCompletion, OnlyOnCanceled, OnlyOnFaulted und OnlyOnRanToCompletion. Die meisten anderen Flags sind nur für parallele Tasks sinnvoll, nicht für asynchrone Tasks. Z. B. AttachedToParent, HideScheduler und PreferFairness ergeben keinen Sinn in der async Welt; DenyChildAttach, LazyCancellation und ExecuteSynchronously sollten immer in der async Welt angegeben werden; und LongRunningnie sollte sein.

Quelle

2013-10-22 21:40:40

Einfache Ausnahmebehandlung war mein erster Ansatz für NotOn * und es ist gut zu bestätigen, dass das in Ordnung ist.Ich werde mir die anderen Flaggen genauer ansehen müssen, um den letzten Teil Ihres Satzes zu sehen;) – natenho

Ich kam hierher, als ich in eine Situation geriet, in der ich die 'HideScheduler'-Flagge angeben musste, und ich konnte nicht . Das Szenario: Eine asynchrone Methode wird von einem GUI-Thread aufgerufen, wobei der GUI-Thread bis zum Ende des asynchronen Aufrufs gesperrt ist. Dies führt zu einem Deadlock, da die Fortsetzung zurück an den GUI-Thread (Warten & Blockieren) gesendet wird. HideScheduler würde den Tag retten. Umgehung: 'neue Aufgabe ({async}, TaskCreationOptions.HideScheduler) .Start()' und warten auf diese temporäre Aufgabe. – robert4

Ich weiß, dass es normalerweise ein schlechtes Design ist, den GUI-Thread während eines Async-Aufrufs zu blockieren, aber dies war ein spezielles Programm: hauptsächlich kopflose Operationen (stellen Sie sich eine Backup-Aufgabe vor) mit GUI während der Entwicklung, nur um Feedback zu geben - unsichtbar/deaktiviert/In der Produktionsumgebung blockiert. – robert4

Ich glaube nicht.

Async/await wurde nicht gemacht, um TPL alle zusammen zu ersetzen, sondern um es zu ergänzen, indem einfache Operationen sauberer gemacht werden.
Wenn Sie noch zusätzliche Konfiguration benötigen, müssen Sie sich an Tasks halten, oder Sie könnten versuchen, einen benutzerdefinierten Warner mit diesem Verhalten zu implementieren.

Quelle

2013-10-22 21:40:27

Wie TaskContinuationOptions mit async/await?

Antwort

Verwandte Themen