sendmsg と recvmsg によるサーバー・モデルは運用時にも耐久性に優れ、
しかも軽々とした最高のパォーマンスを引き出すことができる、という
理想的なサーバー・モデルである。
欠点は何もないのだろうか ?
実はこの理想的なサーバー・モデルであっても次の2つの問題点があった。
- 子プロセスがすべて活動中であるときは要求メッセージを受け取る子プロセスがいないことを親の Alaska が検知することができない。
- 子プロセス内で CGI の標準出力を処理できない。
1. は親の HTTPサーバーはメッセージを子供達に sendmsg で配布はするが
誰かが、そのメッセージを受け取ったのかは一切関知しないからである。
つまり指示書はバラまいたもの、どの作業者が指示書を受け取ったのか、
あるいは誰も受け取ることがなかったのか知るよしもないのである。
2. に関しては一般に pipe が使用される場面は spawn によるジョブ投入であり
自分自身の同一プロセス内で pipe が使われることはなかった。
子プロセスからさらに孫プロセスを生むのであれば、またもやパフォーマンスの
低下の原因となるので、モデルとして採用される基準には達しないのは当然である。
■ pipe による解決
理想的と思われた sendmsg と recvmsg によるサーバー・モデルで見つかった
上記の２つの問題点は どちらも pipe によって解決することができた。
1. は sendmsg と recvmsg は元々対となる2つの socket 識別子で構成されているのだから
それらを予め pipe で結んでおいてメッセージを受け取った子プロセスが pipe を通じて
親の HTTPサーバーに受け取った旨を通知することで簡単に解決した。
メッセージを受け取った後のことなのでパフォーマンスにも殆ど影響もなかった。
誰かが、そのメッセージを受け取ったのかは一切関知しないからである。
つまり指示書はバラまいたもの、どの作業者が指示書を受け取ったのか、
あるいは誰も受け取ることがなかったのか知るよしもないのである。
2. に関して同一プロセス上で標準入出力を pipe で結ぶ必要がある。つまり、
という構図を実現しなければならない。