Blocking Monad

Blocking-Preserving の問題をもうちょい考える.そもそもある Filter が Blocking-Preserving であるとは,「その Filter に対する read/write の要求サイズに対して返される返答が要求サイズより小さくなるのは, Filter の下位にある Device が EOF に達しているときかつそのときに限る」という性質である.
この性質が重要な理由は, Filter の部分で要求サイズより小さいサイズだけ入力・出力してしまうと, Filter の下位にある Device で Block されたかどうかの情報(これは Device に対する read/write で,要求サイズより小さいサイズが入力・出力されたという情報から伝達される)が失われてしまうためで,結果, Device が read/write を Block していなくても Filter を合成した結果の Device が Block しているように見えてしまう,という状況が発生する.これを回避するためには,

  • 個々の Filter を全て Blocking-Preserving として実装する
  • Blocking-Preserving でない Filter を合成する際に,その Filter オブジェクトに Blocking-Preserving とするようなアダプタをかます

あたりが考えられるけれど,前者は

  • 個々の Filter の実装全てに Blocking-Preserving を満たすためのロジックが重複していやんな感じ
  • Blocking-Preserving でない変換を Blocking-Preserving にするためにはバッファリングが必要になる.これが合成する個々の Filter 全てに必要になるため,効率の観点でいやんな感じ

という欠点を抱える.後者も前者の2点目の問題と同様な状況に陥る.
しかし全体から見れば,中途の Filter は Blocking-Preserving でなくてもまったく構わず,ただベースの Device が read/write を block しているかどうかの情報を伝達しておいて,最終的な合成結果のところだけ Blocking-Preserving を満たすためのバッファリングを行えばよいだけである.したがって代わりに,「デバイスが read/write を block しているかどうか?という付加的な情報を付与・生成する read/write を考えて,そのような『ベースのデバイスが block しているかどうかという付加的な情報』を付与された(blocking-preserving でない)メインのフィルタ処理を合成するするような計算機構」があれば良い……というところまで考えた.まる.