APRが使われない理由

id:kanbayashiがAPRについて書いていたので、最近Apache Modules Bookを読んでホヤホヤの僕が反応してみますよ。

気持ちはすごく良くわかる。Cでプログラムを書いていると、リストとか可変長配列とか可変長文字列とか、いろいろ使いたくなる。だけど、僕が知る限り、データ構造を網羅している便利なライブラリで、ポータブルっていうものは存在しない。たぶん。Linuxな人はglibcを使うけどね。いや、探せばあると思うけど、誰もこの「業界」で覇権を握っているようには見えない。

追記：glibはGimpとかがWindowsにポーティングされているようにマルチプラットフォームだけど、積極的に使っている人がいるかというと？？？な印象。やっぱりそもそもCでアプリケーションを組むということ自体が少ないのかな。組み込みとかOSとか言語処理系くらいなもんで。id:QtGqCwfDSAさんありがとうございました。

で、その例外(？)がAPR（Apache Portable Runtime）だ。これも、リストとか配列とか文字コード変換とかネットワーク関係とか網羅してくれていてさらにポータブルだから、非常に便利だ。Cの基盤ライブラリはこれで決まりっ！…と思いきや、やはり、広く使われている気配はない。せいぜいSubversionが使っていることが有名なくらい。

その原因は、APRの独特なメモリ管理方式にある。そう、いつでもメモリが問題なのだ。Memories are always matter.

APRは、メモリ領域をpoolという形で確保する。これは、領域ひとつひとつを確保／解放する代わりに、いくつかまとめて確保してまとめて解放する、という方式だ。これだと、解放のコードが非常に少なくなるから、メモリ関係のエラーがガクッと減る。

この「まとめて」というのがミソで、当然、いろんなところで１つのpoolからメモリを確保した場合は、いつまでたっても解放できないことになる。あるpoolから確保したメモリがすべて「用済み」になったことを確信できないと、解放できないのだ。

え、Apacheなんていう巨大なアプリケーションが、こんなメモリ管理方式で問題ないのか？

それが、問題ないのである。それは、HTTPサーバーというソフトウェアの特殊性として、「処理がリクエスト単位に簡単に分割できる」というのがあるからだ。ひとつのリクエストを受け付けて、パースして、ロジックの処理をして、レスポンスを返して終了、という(比較的）短時間の完結した処理が平行して走る、というHTTPサーバーの大きな特徴があるから、APRのメモリ管理が生きてくる。ひとつのリクエストが終了すれば、それに関わるメモリ領域は全て「用済み」に決まっている。

もちろん、メモリはリクエスト単位で必要なものだけではないから、Apacheの拡張ライブラリを書く場合なんかは、いろんな粒度でのpoolがモジュール側に渡される。リクエスト単位、コネクション単位、スレッド単位、プロセス単位などなど。

そういう意味でHTTPサーバの対極にあるのは言語処理系だろう。ある場所で確保したメモリが、どのくらいの時間生存してどこで使われていつ用済みになるのかがまったく予測できない。

まあ、いまどきアプリケーションを全部Cで書く意味があるかどうかっていうのは疑問だよね。APRを使って全部Cで書かれたSubversionより、大半がPythonで一部CのMercurialの方が速いっていう話もあるし*1。

追記：ごめんなさい、ID間違ってました。twitterと同じだと思い込んで書いたら違った。

The Apache Modules Book: Application Development With Apache (Prentice Hall Open Source Software Development) Nick Kew Prentice Hall 2007-01-26 売り上げランキング : 26542 Amazonで詳しく見る by G-Tools

*1:自分で試したわけではないです