Frameworkではそれらしきものが採用されているものの、そんなに広く使われているわけでもなさそうだ。IOUパターンは、非同期IOを同期IOモデルのように、オブジェクトの利用者に見せかけるためのパターンで、非同期IOの結果をまるで同期IOのように、呼び出し側に返す。同期IOではなく、すぐに返す。そのため、呼び出し側はお話にならないエラーはすぐに検出できる(これは同期IOでも同様。クローズ済みIOに対してメソッドを呼んだ場合)。ない、たぶん、実行されるであろうIOについても、すぐに戻る。結果として返されるオブジェクトは、同期IOの場合と異なり、IOUオブジェクトだ。Vermeulenによって以下のように定義されている。IOUとは、サプライヤ(呼び出された関数)からのアグリーメントであり、約束したオブジェクトを提供することによって最終的に閉じられる。IOUが閉じられてしまえば、サプライヤが提供したオブジェクトでIOUを償還すればよいのである。それまでの間プログラムコードは、他の有用な作業を続けることができるのだ。IOUの概念は、2つの理由により有効である。IOUをリターンする関数の呼び出しは、そうでない関数の呼びだしと全く同じに書くことができる。第2にIOUは、サプライヤが使用する非同期機構(もしあればだが)から完全に独立していることである。2番目の有効性については、IAsyncResultがまあ証明していると言える。以下に、Rubyで実装したIOUの例を示す。1.1の送信と受信をカプセル化する。チャンクの処理はいい加減だがやっつけ仕事の意味のハックなのでしょうがない。最後のIOUの完了を待つ。sock.shutdownendここでは、見掛け上は同時に複数のクェリーをGoogleに対して実行する。実際には1つのコネクションを利用して、一問一答形式で行われる。15:4回結果を表示しているのは、最後のIOUに対してredeemメソッドの呼び出しとasync_callbackの呼び出しが行われているからだ。通常はどちらか一方を利用することになる。このプログラムは1.8.7、1.9.1の両方で実行できるが、1.9.1では標準出力をスレッド間でシェアしているためか、改行が他のスレッドの出力に食われて正しく処理されなかったりするようだが、そういうものなのだろう。ここで示したIOUの実装例では、実際のIOはスレッドを利用して同期的に行っている。仮に非同期IOを利用するように変えたとしても、それは呼びだし側にとってはIOUによって隠されているため、呼び出し側のコードには影響しない。これでこのDDJJを捨てられる。LeaのFutureパターンと動機と実装がほぼ同じ感じですね。19:33)詳細を隠す(IOUの第2の目的)という意味では似ている(実装含め)と思いますが、IOUの第1の目的は、非同期IOを同期IO並みに呼び出し側にとって単純にする(呼び出し側は非同期IOを意識する必要があるので、戻り値としてIOUを返す。Futureは単に意識させないのだと思います)で、むしろそこが肝だと思うので、僕にはそれほど似ているようには思えなかったです。