　次に寄せられた要望は、当たり前のものでもあり、黒田（くろだ）歩（あゆむ）にとっては避けて済ませたいものでもあった。個々のwormが別個にサイト内のページに対して検索をするのは効率がいいとは言えないというものだった。

　それを効率的に行なうには、サーバ権限により、あるいは他の権限により、そのサイトに存在するページに現われる語句のインデックスを作成する必要があった。それを行なうには字句解析が必要であり——それ自体はもちろん可能だが——、加えてサーバとDBMSの統合が必要だった。

　さらには、wormが保持するキーワードと字句解析の齟齬への対応も必要だった。字句解析の機能が、たとえば「字句解析」を「字句」と「解析」としており、wormにおいては「字句解析」がキーワードとなっているような場合への対応が必要だった。これに対応するには、wormが保持するキーワードに対しても字句解析を行ない、その結果の and あるいは or を検索の結果とする必要があった。

　これらは不可能ではないが、サーバの資源を消費する。そのため、サーバの本来の機能であるページ参照の解決とデータの転送に影響を与えることを懸念した。

「どこも高スペックのサーバを使っていれば、こんなのは問題じゃないんだが」

　しかし、それを期待することは、あるいは前提とすることはできなかった。

　他に方法がないわけでもなかった。一つのwormの検索結果を、そこに存在する他のwormにブロードキャストする方法もあるだろうし、より簡単にwormが参照する黒板（ブラック・ボード）を用意する方法もあるように思えた。だが、どちらの場合も問題は残るように思えた。ブロードキャストするのであれば、結局のところwormによる検索の回数はそれほど減らないだろう。ある時点において、あるサーバに存在するwormのみが、ブロードキャストを受信する対象になるからだった。そして黒板（ブラック・ボード）を使う場合であれば、適切にファイルのロックが行なわれなければ、デッド・ロックが発生するかもしれなかった。黒板（ブラック・ボード）を読み込む場合には問題にはならないが、書き込む場合には注意が必要だった。デッド・ロックを回避するためには、できるだけ低レベルにおいて実行する必要があった。そして、現状においては、wormの実行系、wormの実行系を実行するJavascriptの変種の実行系を通してロックを行なう必要があり、複数のwormがロックの動作に入った時に、既にロックされていることを確実に確認することには問題があるように思えた。

　だが、黒板（ブラック・ボード）による方法は魅力的ではあった。

「C言語のflockを直接叩ければいいんだが。あるいはセマフォが確実に、即座に実行されれば」

　しかし、それは実装上困難な問題ではあった。wormの実行系からできるだけ直通にする方法はある。FORTH 83-Standardを参考にしたのも、そのシンプルさから、ここでは利点になるように思えた。あとは、Javascriptの変種の実行系において適宜複数回ロックされているかどうかを確認し、デッド・ロックを回避するしかなかった。

　一つの確実な解決方法は、シリアライズであった。しかし、それはwormが各々プロセスとして動いている現状の実装を変える必要があった。シリアライズが行なえるなら、wormの実行系を実行しているJavascriptの変種の実行系も、各々プロセスとして動いているという無駄を排除できることにも繋がる。問題は、どのようにシリアライズをするかだった。

　仮にwormの到着順に実行するというシリアライズを行なった場合——これが一番簡単そうではあったが——、混雑した場合の待ち時間の予測が立たないという問題があった。そして、個々のwormが自律的に動作しなくなるため、待ち時間によっては一旦別のサーバに退避することも困難になるように思えた。

　到着したwormの先頭部分に到着時刻を記録し、wormの実行系を実行しているJavascriptの変種の実行系において経過時間を求め、一定時間を経過していたならwormの移動の機能に実行を移す方法はあった。

「ロックとこちらとどちらが確実で、さらには簡単か」

　シリアライズは、Javascriptの変種の実行系の動作を大きく変える必要があった。なにより、wormの自律性が奪われるのは、歩としては避けたかった。それが最善の選択ではないとしても。

　教授から、一週間、ワークステーション一台を専用に使う許可を得ると、歩は両方のバージョンを作り、高負荷下での実験を行なった。シリアライズを検討に加えたことは無駄ではなかった。実行されるwormの数の上限を制御できるようになったからだった。それは、要望ではなく懸念として送られてきていたものに対応することでもあった。