異步CTP - 環境CancellationToken和IProgress

Question

記住異步CTP通過環境SynchronizationContext促進隱式調度，是否有任何理由爲什麼我不應該使我的CancellationToken和IProgress環境呢？

我目前正在通過這些方法，很像我通過TaskScheduler周圍顯式調度。然而，看到調度器現在應該是環境的，可能我不遵循相同的規則來解決其他難題？

Answer 1

CancellationToken對於這個比IProgress<T>更可能。在IProgress<T>中，您經常在不同的級別使用不同的T（更高級別的async方法組合了其低級await調用的進度通知）。用CancellationToken，同樣的道理幾乎總是傳遞給更低層的方法（假設它們支持取消）。 CancellationToken確實支持一些非常先進的組合器，但它們很少被使用。

主要的缺點是你會離開基於任務的異步模式。您必須記住，任何微軟或第三方代碼都會採用明確的CancellationToken - sp，您必須明確將其從最低級別async方法中的環境上下文中提取出來。此外，稍後維護代碼庫的程序員可能會期待TAP。

當您考慮實施時，還有一個挑戰。即使它們更改了線程上下文，您也會希望隱式CancellationToken遵循async方法的調用。我的意思是，考慮這一點：在等待方法B的結果之前，方法A調用ConfigureAwait(false)。您不能使用簡單的線程局部靜態屬性，因爲您需要遵循異步執行上下文從一個線程到另一個線程。

我似乎還記得有關如何執行此操作的方法（可能使用CallContext類？），但只要您執行此操作，性能坦克（執行上下文遷移代碼已針對默認方案進行了高度優化）。