個人的なメモです．

* 設計

  o データの持たせ方

    オンメモリでプロセス毎にデータ持とうという発想が間違いなのか．フォー
    マット済みHTML を生成して，OS の Disk Cache に任せれば良いじゃん．

    なんか避けてたけど，共有メモリ使った方が良いかも．

  o Apache のモジュールである利点

    動的にコンテンツを変える必要があまりないアプリケーションには向いてない気がする．

    → そもそもの作成動機が，

       - インタプリタ(もどき)の作成
       - C++ によるプログラム作成

       だったので気にしない．

    本当に高性能なアップローダ作るんだったら，ソフトを Apache モジュー
    ルに置き換えれば全て解決，みたいな発想は間違ってます．

* ハマりどころ

  o APR_INT64_C

    C++ の場合，__STDC_CONSTANT_MACROS を定義しておかないと INT64_C が
    定義されず，APR_INT64_C も使えない．(stdint.h)

* デバッグ

  o アップロード処理でのメモリ消費

    Apache 2.x で POST されたデータを読み込むには次の二つの方法があるが，
    2. の方法はリクエストのサイズに比例した(大体 1/40)のメモリを
    Apache 内部で消費してしまう模様．
  
    1. apr_brigade_create, ap_get_brigade, apr_bucket_read
    2. ap_setup_client_block, ap_should_client_block, ap_get_client_block

    この現象は，以下のコードを使って VmSize を監視することで確かめました．

    > static int test_handler(request_rec *r)
    > {
    >     if (strcmp(r->handler, "test")) {
    >         return DECLINED;
    >     }
    >     r->content_type = "text/html";
    > 
    >     if (!r->header_only)
    >         ap_rputs("The sample page from mod_test.c\n", r);
    > 
    >     {
    >         apr_file_t *out;
    >         char buffer[1024];
    >         apr_size_t size;
    >         apr_status_t status;
    > 
    > 
    >         if ((status = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
    >             return status;
    >         }
    >         if (!ap_should_client_block(r)) {
    >             return HTTP_NO_CONTENT;
    >         }
    > 
    >         if (apr_file_open(&out, "/dev/null", APR_WRITE,
    >                           APR_OS_DEFAULT, r->pool) != APR_SUCCESS) {
    >             return HTTP_INTERNAL_SERVER_ERROR;
    >         }
    > 
    >         while ((size = ap_get_client_block(r, buffer, sizeof(buffer))) != 0) {
    >             if (apr_file_write_full(out, buffer, size, &size) != APR_SUCCESS) {
    >                 return HTTP_INTERNAL_SERVER_ERROR;
    >             }
    >         }
    > 
    >         apr_file_close(out);
    >     }
    > 
    >     ap_rputs("Hello!\n", r);
    > 
    >     return OK;
    > }

  o メモリ周り

    普通に build すると pool のおかげでメモリ周りのバグが見つかりにくい
    ので，CPPFLAGS += -DAPR_POOL_DEBUG して build する．

  o コンパイル，Apache 再起動, 確認，は時間かかりすぎ．

  o 「確認」は HttpUnit とか使えば自動化できそう．でも，期待される動き
    を検証するロジックのコーディングがだるそう．

    JMeter が使えるかも．でもなんかめんどくさそう．

  o ダミーの request_rec や apr_bucket_brigade 等を生成する関数欲しい．
    みんなどうやって，コードをテストしてるの？

  o 複数のコンパイラ

    なんだかんだいっても，複数のコンパイラで警告なしでコンパイルできる
    ようにするのが，一番使えるデバッグ方法の気がします．ICC や VC.NET
    使ってなかったら未だに見過ごしてたバグが結構あったと思う．

* その他

  o APR の排他処理周りの関数が apr_status_t を返すのはやめて欲しい．

    APR_SUCCESS 以外のことを考えると，コーディングが結構面倒．
    Java がうらやましい...

  o shared_ptr を早く標準に入れて欲しい．

    でも，こういうのってあれば便利だけど，多用するとコードの見た目がか
    なり汚くなってしまうので，どうなんだろう．typedef 使えば良いじゃん，っ
    ていう話なのかな？

  o Visual C++ .NET 2003 で __VA_ARGS__ が使えないのなんとかして欲しい．

  o ImageImagick のヘッダが warning を吐くのがいやな感じ．
