[kansaipm] use & fork

Sat Oct 4 01:49:02 CDT 2003

# From: Dan Kogai <dankogai at dan.co.jp>
# Subject: Re: [kansaipm] use & fork 
# Date: Sat, 4 Oct 2003 00:25:52 +0900

> 弾です。はじめまして。

はじめまして、杉田です。よろしくお願いします。

> これであれば、わざわざdaemonでやるより、mod_perlなどを使ってapacheの中でやってしまう方が早いかもしれません。

それも考えたのですが、先のメールにも書いたように関数の使用制限が
少し気になっています。

> これは、よくある require と use に対する誤解です。requireと違って、useは実行＜前＞に評価されるので、たとえ  
> script の一番最後に use していても、すでに評価済みなので、すでに親processが実行された時点で終わっています。
> 
> 例えば、
> 
> defined (my $pid = fork()) or die;
> if ($pid == 0){ # child
>    do_child()
>    #
> }else{          # parent
>    #
> }
> sub do_child{
>    use Module_For_Child;
>    #
> }
> 
> というcodeでも、Module_For_Child.pm の評価は、実際にdo_childが呼ばれる前に終わっているのです。

あ、はい、これはよくわかっています。
今回問題になっているのは、コードで書くと以下のような場合です。

if ($pid == 0) {
  do_child();
} else {
  # main
}

sub do_child {
  eval <<"_END";
use MyModule;
hogehoge;
hogehoge;
hogehoge;
_END
}

実際には、evalの中身はファイルから読んでくることになります。
これだと、forkされたあとに子プロセス側でuseがかかるので、
childプロセスが終了したときには、コンパイル結果がなくなってしまうと
思いますが、間違いないでしょうか?

昨日、元のメールを書いたあとにthreadsプラグマの解説を読んでみたのですが、
こちらだと、useした結果は、すべてのスレッドで共有されるのですね。

＃ちなみに、
＃  require module; import module hoge;
＃だと、共有されないそうです。

でも、これでも、コードリファレンスがスレッド間で共有できないので
evalした結果をキャッシングすることができないのです。

> > いくつか考えてみたのですが、どうもしっくり来るものがありません。
> 
> これらは実は特効薬はなく、実際の開発の現場では、プロトタイプを作って評価試験をやって決める場合が多いです。fork()の重さ一つとっても、環境 
> によってまちまちです。
> 
> 経験上は、この手のプロジェクトは、下手にserverを作るより、mod_perlで内部的に直接やる方が速いことが多いですが、認証系が絡むと 
> mod_perlの神通力も通用しないこともあります（mod_perlのmoduleはhttpdのUID/GIDに縛られてしまうので）。
> 
> しかしその前に、use に対する誤解があるところから見ても、performance  
> tuning以前のレベルに失礼ながら私には見えてしまうのですが。
> 
> まず、スピードはさておき動くものを作ってみましょう。その後で、どこを optimize するかを考えても遅くおそくありません。

ご忠告ありがとうございます。
useの誤解の件は、上記のサンプルコードでご理解頂けると思いますが、
動くものというレベルでは、すでに、一度 fastcgi で動くものがすでに
一度できあがっています。
もう少し完成度が上がれば公開してもいいなと考えているのですが、
現状では、このプロジェクトを使った業務のこともあり、みなさんに
お見せできない状態です。
（この議論の問題が解決すれば、今回のプロジェクトは直接からんでくる
  クライアントもいまのところないので、公開しながら開発しても
  いいのではないかと考えています）

mod_perlとは少し違いますが、fastcgiもプロセスを落とさずに使い続けると
いう時点で、useでコンパイルされた結果を保持し続ける部分はmod_perlと
似たような効果があります。
ただ、fastcgiには同時起動プロセス数というパラメータがありますが、
これでは、複数のプロセスを立ち上げた場合、プロセスごとに
コンパイル結果をキャッシュすることになるので、メモリの点でも
実行速度の点でも効率が悪いのです。

この部分をどうにかして、今回のプロジェクトで改善したいと思い、
デーモンでやってはどうだろうと考えたのですが、なかなかうまく
いかないものですね。

ちなみに認証系に関しては、サーバーOSの認証は全く使わずに
独自のユーザーテーブルを用いることを想定しているので、
uid/gidがある特定のIDに拘束されることは気にしていません。

／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／
 SUGITA Toshinori 杉田 敏典      Digital Pad Inc.    .・.         
   E-MAIL  : sugita at d-pad.co.jp                       ●・
   WebPage : http://www.d-pad.co.jp/
   メール・スクランブル http://www.d-pad.co.jp/mail/scramble/
   アンケートしよう！   http://www.d-pad.co.jp/enquete/make/
   有名人にメールしよう http://www.d-pad.co.jp/mail/fame/
   アクセス解析サービス http://www.d-pad.co.jp/inspect/