Lucian Wischik氏が公開している一連のブログ記事は、アニメーションの終了を待つことから、コマンドラインプログラムの結果をキャプチャするまでの、広範囲の状況でどうのようにAwaitを使用できるかを示している。
基本パターンは彼の記事でいかにストーリーボードをawaitするかに説明されている。その中核は TaskCompletionSourceである。ストーリーボードがその完了イベントを点火すると、それに関連付けられたイベントハンドラーは、 TaskCompletionSourceを使って Taskに結果を渡す。
このお陰で、シンタックス“Await storyboard1.PlayAsync()”このお陰で、シンタックス“Await storyboard1” で良く、GetAwaiterという拡張メソッドを作ることができ、それに TaskAwaiterを変えさせることができる。コンパイラーはこの名前のメソッドを探し、適宜コードを書き換えてくれる。
このイベントハンドラーベースのアプローチにもっと複雑な例は、How to await a MediaElementにある。これは2つの関数OpenAsyncと PlayAsyncを作成する。いかにエラーハンドリングが綺麗な方法でサポートできるかが説明されている。
Lucian氏のRunCommandLineAsyncは、コマンドラインプログラムから標準出力と標準エラーのストリームの両方を読むことをサポートしている。前述の2つのストリームと入力ストリームとのやり取りのために、このようにするのは最初、思う程簡単ではない。氏はこのためにいかにマルチタスクが使われているかを説明している
“RedirectStandardInput/Output/Error”の正確な動きは、起動したプロセスの内部詳細に依存する。我々が確実に言えるのは、(1)プロセスは、その StandardInputをクローズするまで終わらないだろう(2)我々は StandardInputにそれ以上のデータを書き込める前に、 StandardOutput/StandardErrorからデータを読まなければならないだろう(3) StandardOutput/StandardErrorからもっとデータを読みことが出来る前に、StandardInputにもっとデータを書き込まなければならないだろう。このような制約は、3つのタスク “tin/tout/terr”は全て同時に起動されなければならず、それからTask.WhenAll()を使って待たなければならない。
いかにコンパイラーで Await と GetAwaiterがやり取りするか、もっと知りたければ Stephen Toub氏の記事何でも待つを読むといい。