国民宿舎はらぺこ 大浴場

まだやってないけど。

CGI 呼び出しによって毎回起動するプロセスを「呼び出し側プロセス」、実際の処理と出力を行うプロセスを「処理側プロセス」と呼ぶことにして。

呼び出し側プロセスの処理は以下の通りかな。

1. 名前付きパイプ pipe_A が無ければ作る。
2. 名前付きパイプ pipe_B を作る。これは毎回、違う名前で作る。
3. 処理側プロセスが存在しなければ fork し、子プロセスを処理側プロセスとして、そのプロセス ID をファイルに記録する。
4. pipe_A を開き、pipe_B のファイル名と環境変数、そして標準入力からの入力を出力する。
6. pipe_B を開き、入力した内容を標準出力に書き出す。
7. pipe_B を削除する。

処理側プロセスの処理は以下の通りかな。

1. pipe_A を開き、pipe_B のファイル名と環境変数、そして標準入力からの入力を入力する (その単位でデータを適切に読み出せるよう、データのサイズがわかるようになっている必要がある)。
2. 処理を行い、結果を pipe_B に書き出す。
3. 1 に戻る。

懸念点。つか、おいらの知識が圧倒的に足りてないだけの話なんだけど。

• 呼び出し側プロセスは毎回起動するわけだからあんまり解決になっていないのでは?
  • 処理側プロセスが大量のモジュールを読み込むような場合には、それなりに効果はあるのかも。
• mod_perl が使えないような環境、すなわちさくらのレンサバみたいなレンタルサーバー環境では、処理側プロセスみたいなのは短時間で kill されちゃうだろうから運用的には効果は薄いのでは?
  • その辺、ログを録ったりして実際の動きを確認してみたい。
  • 実際に使われているシグナルの種類次第では、トラップして無視って運用もありかも。。。 (危険!!^_^;)
• パイプによる通信コストは無視できないのでは?
  • これが一番のネックになりそうな気がする。もっとマシな方法がありそうなんだよなぁ確かに。。。
• pipe-A はセマフォ的なアクセス制御が必要では?
  • アクセスが集中した場合、呼び出し側プロセスの待ち行列を DB か何かで管理して、行列が一定数を超える場合は 503 エラーにしちゃう、みたいな運用かなぁ。
• mod_perl で動かせる環境との間で可搬性が失われるのでは?
  • そこはあまり心配してない。 mod_perl 用に別途インタフェースを用意して、どっちからでも同じように呼び出せるような作りにするのはいくらでも可能なはず。

以上、妄想メモ。