Async CTPはアンビエントを介した暗黙のスケジューリングを促進することを念頭に置いて、私もアンビエントSynchronizationContextを作成すべきではない理由はありますか？CancellationTokenIProgress
私は現在TaskScheduler、明示的なスケジューリングのためにアラウンドを渡すのと同じように、これらをメソッドに渡します。ただし、スケジューラーがアンビエントであると想定されているので、パズルの他の部分についても同じルールに従うのではないでしょうか。
CancellationTokenよりもこれの可能性が高い候補ですIProgress<T>。を使用IProgress<T>すると、多くの場合、レベルごとTに異なります（高レベルのasyncメソッドは、低レベルのawait呼び出しの進行状況通知を組み合わせます）。を使用CancellationTokenすると、ほとんどの場合、同じトークンが下位レベルのasyncメソッドに渡されます（キャンセルをサポートしていると想定）。CancellationTokenいくつかの非常に高度なコンビネータをサポートしていますが、ほとんど使用されていません。
主な欠点は、タスクベースの非同期パターンから逸脱することです。Microsoftまたはサードパーティのコードは明示的に取得することに注意する必要があります。つまり、最下位レベルのメソッドCancellationTokenで周囲のコンテキストから明示的にコードを引き出す必要があります。asyncまた、後でコードベースを保守するプログラマーは、TAPを期待する可能性があります。
実装を検討する際にも課題があります。メソッドがスレッドコンテキストを変更する場合でも、暗黙的にメソッドCancellationTokenの呼び出しに従う必要があります。asyncつまり、次のことを考慮してください。メソッドの結果を待つ前にメソッドAを呼び出します。あるスレッドから別のスレッドへの非同期実行コンテキストに従う必要があるため、単純なスレッドローカル静的プロパティを使用することはできません。ConfigureAwait(false)B
これを行う方法（おそらくCallContextクラスを使用しますか？）について読んだことを思い出しているようですが、それを実行するとすぐにパフォーマンスタンクになります（実行コンテキストの移行コードはデフォルトのシナリオ用に高度に最適化されています）。