3

Stephen Toub のAwait Anythingブログ投稿には、カスタム awaiter の興味深い例がいくつかあります。await task.WithCulture()実生活で役立つと思うパターンが特に好きです。ただし、 で実行できない可能性があるものは他に考えられませんTaskCompletionSource。

役に立つかもしれない興味深い分野の 1 つは、Stephen のブログやこの質問のように、実行コンテキストのControlAwaiter切り替えです。しかし、これは良い習慣とは見なされていません。ContextSwitcher

コードの可読性と保守性を損なうことのないカスタム awaiter の実用的で有用な例を他にもいくつか見ると興味深いでしょう。

4

1 に答える 1

7

カスタム awaiter の現実的な使用例はほとんどありません。

ただし、これらのカテゴリのいずれかに当てはまると思われる例がいくつかあります。

  1. Taskパフォーマンス上の理由から回避します。Windows ストア プラットフォームは、(管理されていない) 非同期操作をカスタム awaitable で公開します。もう 1 つの例は、高トラフィックのメモリ集約型シナリオで使用される特殊な非同期 API用の Stephen Toub の awaitable ラッパーです。Socket
  2. 既存の待機の動作を変更します。たとえば、ConfigureAwait(false)またはWithCurrentCultureあなたが言及した .
  3. awaitable の再利用を有効にします。このブログ投稿の「イベント awaiter」タイプは、発生したイベントごとに1 つを満たしawaitます。対照的に、タスクは 1 回しか完了できません。

Task.Yieldもカスタム awaitable を使用していますが、独自のカテゴリにあるようです。

個人的には、カスタムの awaitable は避けています。通常、カテゴリ (1) は時期尚早の最適化としてのみ考慮されます。カテゴリ (2) は概念的には興味深いものですが、よく調べてみると、動作修飾子がうまく構成されていないことがわかります。カテゴリ (3) も興味深いですが、完了のセマンティクスが驚くべきものである可能性があるため、より物議を醸す IMO です。

于 2013-10-23T14:38:30.190 に答える