[PHP-users 3060] Re: mbregex のインストール

[Osamu Shigematsu]

重松です。こんにちは。

>> あと、PHP 4.x の mbereg() は ruby ゆずりみたいですけど、
>> GNU のコードの malloc() に失敗したときにそれを確認しないバグを
>> そのまま引きずっているようなんですけど、これって、私の
>> ソースコードの読みまちがいでしょうか?
>> PHP-dev で同じネタを質問したのですが、情報を頂けなかったので、再度。
>> # ruby は malloc() には失敗しないですが、PHP も失敗しない?
> 
> ご心配は理解しますが、バグでもないという反論をすると、
> ・メモリが足りなくならないように運用するものだ
> ワークステーションで作業していてメモリが足りなくなるのと、
> webサーバーで接続がたくさんきてメモリが足りなくなるのは、
> かなり状況が違うと思います。
> オブジェクト指向の実行環境でガーベージコレクタというのは、
> 暗黙のデストラクタとか、メモリブロックのフラグメントの
> 掃除などをうまく調整して、性能を向上させるものだと思いますが、
> webアプリケーションの場合は、ガーベージコレクタを起動しても、
> 回収できる領域はそれほど無くて、かえって状況を悪くする
> という事態も考えられます。
> 十分なメモリを用意して、手早く処理を行い、さっさと終了する
> というのが、HTTPのアプリケーションの基本だと思います。

というのはもちろん理解できますし、おそらくおっしゃっているように、
GC を実装するのは特に効率が良くなるとは思えません。

# それほど、悪くもならないでのではと思いますが、
# 実装・保守にかかるコストに見合った効果が得られないとは思います。

> ・メモリが無ければ作業をやめるしかない
> 必要なときに、それがないとどうしようもないのですが、
> その際に後始末をすべて書いていたら、例外処理が多く
> なってしまい、面白くありません。
> malloc() が失敗しないというのも、メモリが無かったら
> そこでプロセスを終了させているのだと思います。
> （ですから、nullポインタを読み書きして、例外が上がって、
> 終了しても、たいして変わりが無い？？）

メモリ不足は常に発生し得るので、それを確認しなくても良いか、
というのとは別の議論だと思いますし、というのと、
確保できなかった場合、以下に安全に作業を中断するのか、と
どうやってメモリを確実に確保に行くのか、というのは別の次元の問題です。

たしかに、メモリ (リソス) 管理がしっかりしていれば、null pointer
アクセスで落ちるでしょうが、そうでない環境もあります。(たとえば、Mac OS)

> 以上は言い訳なのですが、
> zend_alloc.h をみてみたら、 persist_alloc というのが
> あったので、
> 
> #define xmalloc(size) persist_alloc(emalloc(size))
> #define xcalloc(nmemb,size) persist_alloc(ecalloc(nmemb,size))
> #define xrealloc erealloc
> #define xfree efree
> 
> とすれば、少しは安心できるかもしれません。

これは、失敗すると、PHP 側が安全に処理を中断してくれるのでしょうか?
通常の malloc() との違いがよくわからないのですが。

あと、あまりに基本的なことですけど、GNU のコードは realloc() の使い方を間違
えているので、それまではフォローしてくれないと思います。
# 単に失敗すればその場で終了するなら別ですが。

たとえば、文字列バッファを確保する場合に、std::string とかは、
現在割り当てているサイズの倍・倍という感じで確保すると思ったんですが、
高速化のために多めに確保しようとして失敗した場合に、ちょうど必要なサイズを
割り当てて、実行を継続しようとするような処理が、malloc() に失敗しただけで、
exit() するならば、できないことになってしまいますね。

いずれにしても、ruby から拝借している以上、malloc() に失敗しない (ように、み
える) ようにするのが、もっと良いと思いますし、PHP 側にメモリ不足で失敗した、
ということまで返せれば、最も良いと思います。

-- 
Osamu Shigematsu

http://www.ravi.ne.jp/%7eshige/
mailto:shige@ravi.ne.jp