[kansaipm] use & fork

[Dan Kogai]

On Saturday, Oct 4, 2003, at 19:42 Asia/Tokyo, SUGITA Toshinori wrote:
> で、更に発生した疑問なんですが、mod_perlはapache上のモジュールとして
> 動作するわけですが、プロセス的には、どのような構成になるのでしょうか?

Apacheそのものと同一のprocessです。mod_perlとは、すなわちperlを内蔵したapacheなので。ですから、親process 
でuseされたmoduleは、そのまま子processでも使えることになります。その意味で、fastcgiよりさらにefficientです。

> これだと、apacheプロセスごとにmod_perlが使用する
> プロセスがあることになるので、コンパイルがプロセス数分
> 行われることになります。これは私の望む動作ではありません。

というのは誤解で、基本的に子processは親processの環境を、useされたmoduleまで含めて全て継承するので、新たなcompile 
は発生しません。

> やはり、複数プロセスでコンパイル結果をshareする（せめてshareして
> いるように見せかける）のは無理なのでしょうか。。。

というのは mod_perl  
では当たり前にやっていることで、Apache::Registryは通常のCGIに対してもそれを可能にする仕組み 
で、Apache::PerlRunはさらに広範囲のCGIに対して（効率を犠牲にして）それを可能にする仕組みだと考えればよいでしょう。

> evalの結果をshere出来ないことを諦めれば、threadsが一番
> 希望するものに近いものができそうですが、こちらでは逆に
> スレッド自身に伴う問題（共有メモリ、スレッドセーフ云々）が
> 恐いので。。。

Perlのthreadはまだそういう意味で実績が少なく、またmod_perlとの相性もあまりよくありません。あえてthreadを使うというので 
あれば、Apache 2にmod_perl  
2を仕込んでやるというのがthreadを使う回答の中では最良だと思いますが、こう申し上げるのも何ですが、threadうんぬん言う前に、もう少し  
*nix の process の仕組みを勉強した方がいいと思います。

あと、「遅い」とか「効率が悪い」というのは、以外と思い込みの部分が大きなものです、きちんと Benchmark  
した上で結論を出しましょう。そのための Tool もPerlにはたくさんあります。

Dan the Man with Too Many Web Applications to Tune