done

drip.txt

@@ -974,12 +974,14 @@ end
 ***クロウラの動作間隔とインデクサの同期
 
 このサンプルで示したかったものの一つに、複数の処理が自分の都合のよいタイミングで動作するというものがあります。
+
 クロウラは定期的に動作を開始します。クロウラはインデクサの状態など気にせずに処理を行い、更新を見つけてはwriteします。
 インデクサも同様です。インデクサはクロウラの動作状況を気にせず、これまでDripに格納されていた文書をまとめて取り出しては索引の更新を行います。文書を処理し終わったら、新しい文書がwriteされるまで休眠状態になります。
+
 データの流れとしては、クロウラが発生源で、Dripに蓄えられて、インデクサがそれを取り出し索引を作ります。しかし、クロウラが発生させた処理の中でインデクサが動作するわけではありません。たとえば、オブザーバーパターンでクロウラ→インデクサとコールバック等のメソッド呼び出しの連鎖のなかで索引更新が行われると想像してみてください。クロウラ側の更新を調べる処理は、索引の更新と直列に動作し律速してしまいます。
-Dripにおけるイベントの通知は、受動的ではありません。リスナ側が自分の都合のよいときに情報を取り出します。取り出す情報が尽きたら、ブロックすることもできます。アクターモデルのように、能動的に新しい情報を取り出すことで動作します。
+Dripにおけるイベントの通知は、受動的ではありません。リスナ側が自分の都合のよいときに能動的に行われます。このスタイルはアクターモデルともよく似ています。インデクサは自分の担当する仕事が一通り終わって、自分の状態が安定してから次の文書を取り出します。dRubyのRMIがサブスレッドにより気付かないうちに実行されるのと対照的ですね。
 
-(途中)
+ややこしい喩え話はともかく、クロウラはインデクサの処理を待つことなく動きますし、インデクサはクロウラの処理の頻度と関係なく自分のペースで動きます。Dripはメッセージングのミドルウェアとして彼らの間をゆるく仲介します。
 
 ***フェンスと足跡
 
@@ -1106,6 +1108,9 @@ boundの仲間にはlower_bound、upper_boundというバリエーションも
   end
 ||<
 
+boundでなくlower_bound、upper_boundを使うメリットはもう一つあります。
+boundの場合、その範囲に入っている要素の数が大きいとき、それだけのArrayをメモリに作ってしまいますが、lower_boundによって少しずつスコープを動かしていけば検索の回数は増えますが、一度に使用するメモリ、RMIであればそのためのバッファも減らすことができます。
+
 順序のあるデータ構造、RBTreeは、実はDripの内部でも使われています。基本となるのはDripのキー（整数のキー）をそのまま使う集合です。もう一つ、タグのための集合にもRBTreeを使っています。この集合は[タグ(String), キー(Integer)]という配列をキーにします。
 
 >||
@@ -1124,7 +1129,7 @@ boundの仲間にはlower_bound、upper_boundというバリエーションも
 
 Rindaの場合は強力なパターンマッチと引き換えに、Arrayを基本としたデータ構造を内部で使っていたため、データ量に比例して検索時間が増加する(O(N))という問題がありました。Dripの場合はRBTreeを使う事でtagやkeyの開始点まで比較的素早くブラウズが可能になっています。(O(log n))
 
-このデータ構造のおかげで「消えないキュー」「いらなくなったら'rbcrowl-begin'でリセット」といった、一見富豪的なデータストアレージが可能になっています。
+このデータ構造のおかげで「消えないキュー」「いらなくなったら'rbcrowl-begin'でリセット」といった、一見富豪的なデータストレージが可能になっています。