Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
Re: [Kai-devel-ja] プロセスプール [was Re: 開発の進め方]
|
From: masahito i. <coo...@gm...> - 2008-07-11 04:08:30
|
▼Erlang ML
実は、今まで Erlang ML を一切見ておりませんでした。
で、先ほど erlang-questions を subscribe しました（。。;;
アナウンスは・・・、tcp_server の edoc を書いてから行ないます。
▼CEAN など
私も手順を解っていないので、これから調べま〜す。
何方か詳しい方いらっしゃいませんか？
2008/7/11 Takeru INOUE <tak...@gm...>:
>>> これを待って，タブ文字の修正などを行いますね．
>>
>> タブの修正も、他の諸々の修正も
>> trunk 側で、バシバシ行なって頂いてかまいませんよ？
>
> trunk にコミットしました．
>
> タブ文字を修正しました．
> あと，コーディングスタイルをいくらか読みやすく改善しました．
> lists:keysearch の代わりに proplists:get_value を使うようにしました．
>
>>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>>
>> まずは、他のメッセージも受け取れるように修正してしまいますね。
>>
>>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>>
>> いつ、誰が、投稿しましょうか？
>> あと、kai 本体のアナウンスが先でも良いかもしれないなーとも思ってます。
>
> そうですね．
> タブ文字の修正も終わったので，sourceforge でリリースして，ML に投げてみます．
>
> tcp_server はメインで書いた cooldaemon さんが投げるのがいいと思います．
>
>>> あぁ，ドキュメントが遅れている．．
>>
>> できる所からコツコツと（汗
>> って事で、kai_tcp_server あたりから書いてみます。
>> 英語 SKILL は娘以下なので、添削お願いしまーす（w；
>
> 誰か英語得意な人いるかな?
>
>> ところで、EDOC に対応が終わったあたりで
>> CEAN とか Erlware に対応する事も
>> 検討しませんか？
>
> はい，手順とか全然分かってないですが，広がりそうなことはやっていきましょう．
>
>
>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>>> merge しました。
>>>
>>> お疲れ様でした．
>>> kai の改良だけでなく，tcp_server まで出来上がって大仕事だったと思います．
>>>
>>>> make test 時、一つの SUITE が終了する際に
>>>> kai_tcp_server_acceptor_N を normal で終了していない為
>>>> エラーメッセージが出ています。
>>>>
>>>> 後日修正します。
>>>
>>> これを待って，タブ文字の修正などを行いますね．
>>>
>>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>>> erlang ML に投げてみてもいいかも?
>>>>
>>>> erlang ML で紹介する事には賛成なのですが
>>>> 心残りが三つ、それから、提案が一つあります。
>>>>
>>>>
>>>> ▼心残り
>>>> 以下、個人的な重要度順です。
>>>>
>>>> １．テスト項目を増やす必要がある
>>>> 早々に、対応せねば。
>>>>
>>>> ２．オプションの active true 対応に見直しが必要かも？
>>>> active を true にするメリットは
>>>> receive でメッセージ待ちをする為
>>>> tcp 以外のメッセージも受信可能となる点です。
>>>> ※勉強不足で勘違いかもしれませんが
>>>>
>>>> 現在、tcp 以外のメッセージを受け取ると exit してしまうので
>>>> Mod:handle_info を評価するように修正しようかと考えておりますが
>>>> 如何なものでしょうか？
>>>>
>>>> （'EXIT' メッセージを受け取った際の処理も必要かも・・・
>>>> んー、gen 関連モジュールの source を参考にしつつ
>>>> erlang ML で意見をもらいつつ修正ってのが望ましいです）
>>>
>>> tcp 以外のメッセージも受け取れるというのは，嬉しい人が多そうですね．
>>> こういうのは erlang ML でプロに聞いてしまうのが早そうです．
>>>
>>>> ３．EDOC に対応する必要がある
>>>> kai 全体に関わるのですが、edoc を採用しませんか？
>>>
>>> そうしましょう．
>>> あぁ，ドキュメントが遅れている．．
>>>
>>>> ▼提案
>>>> kai_tcp_server を、tcp_server に改名しませんか？（もしくは、ptcp_server）
>>>> 何となくですが、その方が他のプロジェクトでも使いやすいかと思います。
>>>
>>> 僕も tcp_server がいいと思います．
>>> p を付けるかどうかは微妙ですが，これも erlang ML に聞くのがいいのかなぁ．
>>>
>>>> ちなみに、kai というプレフィクスが消えた後も
>>>> kai のリポジトリで管理続投が良いと思います。
>>>>
>>>> ※ smerl も、元々は、単独のリポジトリで管理されていましたが
>>>> 現在は、erlyweb のリポジトリで管理されています。（他に使っているプロジェクトが無いからという噂もw；）
>>>
>>> なるほど．
>>> 他のプロジェクトの参考になる部分は積極的にマネしていきましょう．
>>>
>>>
>>>> 2008/7/9 Takeru INOUE <tak...@gm...>:
>>>>> 今日はエラーが出ませんでした．．
>>>>> なんだったのかなぁ．．
>>>>>
>>>>> 接続数が制限されるのを確認しました．
>>>>> merge していいと思います．
>>>>>
>>>>> コードも一通り見せていただきましたが，とっても erlang らしくて感動しました．
>>>>> 近いうちに，すべてのコードのタブ文字を修正しますが，コードの書き方も cooldaemon さんっぽく直しておきます．
>>>>>
>>>>> kai_tcp_server を kai でしか使わないのはもったいないですねぇ．
>>>>> erlang ML に投げてみてもいいかも?
>>>>>
>>>>>
>>>>> 2008/7/8 masahito ikuta <coo...@gm...>:
>>>>>> MacOSX 10.5.4、MacOSX 10.4.11、FreeBSD 6.3 + R12B-3 で確認しましたが
>>>>>> 特に動作に問題は無いように思われます。
>>>>>> ※FreeBSD を使う場合は、Makefike 内の make を gmake に修正する必要あり
>>>>>>
>>>>>> ちなみに、下記メッセージは、エラーではないですよね？
>>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>> [{{{192,168,1,225},
>>>>>>>>>> 11011},
>>>>>>>>>>
>>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>> 128}]}],
>>>>>>>>>> []}
>>>>>>>>>>
>>>>>>
>>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>>
>>>>>>> - src/kai.app.src はデフォルト値
>>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>>
>>>>>>> というつもりでいました．
>>>>>>> erlang の一般的な使い方的にあってます?
>>>>>>
>>>>>> あってると思います。
>>>>>>
>>>>>> ただ、今回のように、設定項目を追加した場合
>>>>>> 二カ所へ追加するよりは、一カ所へ追加して終わりとした方が
>>>>>> 修正漏れが減るのではないかと思います。
>>>>>> （テストも用意した方が良いでしょうねー）
>>>>>>
>>>>>> 2008/7/8 Takeru INOUE <tak...@gm...>:
>>>>>>> application:start(kai). したときに同じエラーが出るなぁ．
>>>>>>> こっちの環境がおかしいのかも．
>>>>>>> また明日みてみます．
>>>>>>>
>>>>>>>> > あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>>> まとめられないものでしょうか？
>>>>>>>
>>>>>>> src/kai.app.src と kai.config ですが，
>>>>>>>
>>>>>>> - src/kai.app.src はデフォルト値
>>>>>>> - kai.config はユーザ用設定ファイル
>>>>>>>
>>>>>>> というつもりでいました．
>>>>>>> erlang の一般的な使い方的にあってます?
>>>>>>>
>>>>>>> あと，kai.config の値はなんでもいいわけなのですが，デフォルト値と同じになっているのが分かりやすいかなと思い，そのようにしてありました．
>>>>>>>
>>>>>>>
>>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>>> ご指摘頂いて箇所のみ修正した版を commit 致しました。
>>>>>>>> 取り急ぎ、ご報告まで〜。
>>>>>>>>
>>>>>>>> 2008/7/7 masahito ikuta <coo...@gm...>:
>>>>>>>>> 結構、抜けありますね…申し訳ないです。
>>>>>>>>> 今晩、修正できるところから対応していきます。
>>>>>>>>>
>>>>>>>>>>N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>>
>>>>>>>>> とりあえず、max_connections のデフォルト値を 30
>>>>>>>>> memcache_max_connections のデフォルト値を 10 にしておきます。
>>>>>>>>>
>>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>>
>>>>>>>>> kai.app の更新をすっかり忘れてました。
>>>>>>>>> んー・・・make をうまく使って、設定を一カ所に
>>>>>>>>> まとめられないものでしょうか？
>>>>>>>>>
>>>>>>>>> 2008/7/6 Takeru INOUE <tak...@gm...>:
>>>>>>>>>> おつかれさまでした．
>>>>>>>>>>
>>>>>>>>>> まだソースは見切れてないのですが，動かしてみていくつか気になった点があったので，とりあえず報告します．
>>>>>>>>>> 動作環境は，R12B-0 (macports) と R12B-3 です．
>>>>>>>>>>
>>>>>>>>>> ■ typo in kai.config
>>>>>>>>>>
>>>>>>>>>> kai.config に "," 抜けがありました．
>>>>>>>>>>
>>>>>>>>>> --- kai.config (revision 372)
>>>>>>>>>> +++ kai.config (local)
>>>>>>>>>> @@ -1,7 +1,7 @@
>>>>>>>>>> [{kai, [%{logfile, "kai.log"},
>>>>>>>>>> %{hostname, "localhost"},
>>>>>>>>>> {port, 11011},
>>>>>>>>>> - {max_connections, 30}
>>>>>>>>>> + {max_connections, 30},
>>>>>>>>>> {memcache_port, 11211},
>>>>>>>>>> {memcache_max_connections, 30},
>>>>>>>>>> {n, 3},
>>>>>>>>>>
>>>>>>>>>> ■ 起動エラー
>>>>>>>>>>
>>>>>>>>>> Getting Started http://kai.wiki.sourceforge.net/getting+started
>>>>>>>>>> の手順に従ってスタンドアローンとして起動すると，次のエラーが出るようです．
>>>>>>>>>>
>>>>>>>>>> % erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1
>>>>>>>>>> 1> application:load(kai).
>>>>>>>>>> 2> application:start(kai).
>>>>>>>>>> 2008-07-06 22:33:35.298615 [info] ./kai_hash.erl:162: {update,
>>>>>>>>>> [{{{192,168,1,225},
>>>>>>>>>> 11011},
>>>>>>>>>>
>>>>>>>>>> [{number_of_virtual_nodes,
>>>>>>>>>> 128}]}],
>>>>>>>>>> []}
>>>>>>>>>>
>>>>>>>>>> =INFO REPORT==== 6-Jul-2008::22:33:35 ===
>>>>>>>>>> application: kai
>>>>>>>>>> exited: {shutdown,{kai,start,[normal,[]]}}
>>>>>>>>>> type: temporary
>>>>>>>>>> {error,{shutdown,{kai,start,[normal,[]]}}}
>>>>>>>>>>
>>>>>>>>>> ■ max_connections のデフォルト値
>>>>>>>>>>
>>>>>>>>>> max_connections と memcache_max_connections のデフォルト値ですが，memcach API に対して
>>>>>>>>>> 1 つのリクエストが来ると，内部 API には N のリクエストが飛び交うことになります．これだけ考えると，max_connections
>>>>>>>>>> : memcache_max_connections = N:1 (たとえば 30:10) とかがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> 一方で，memcache API は内部 API の処理が終わるのを待つことになります．つまり，memcache API のほうが内部
>>>>>>>>>> API より処理時間が長くなります．これを考えると，30:15 のように memcach API
>>>>>>>>>> の値を大きくしたほうがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> さらに，内部 API は，memcache API だけでなくタイマから呼ばれることもあります．たとえば，定期的な bucket
>>>>>>>>>> 同期などです．これを考えると，40:15 のように内部 API 野間対を大きくしたほうがいいのかなと思います．
>>>>>>>>>>
>>>>>>>>>> まぁ，いろいろと考えてみましたが，実際のところは実験してみないとよく分からないので，N:1 (30:10 とか) くらいが妥当かなと．
>>>>>>>>>>
>>>>>>>>>> あと，src/kai.app.src と kai.config で値を変えているのには意図があります?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2008/7/6 masahito ikuta <coo...@gm...>:
>>>>>>>>>>> 一通り実装が終わったのでご報告申し上げます。
>>>>>>>>>>> http://kai.svn.sourceforge.net/viewvc/kai/branches/cooldaemon_embed_tcp_server/
>>>>>>>>>>> たけまるさん OK を頂ければ本体に merge します。
>>>>>>>>>>>
>>>>>>>>>>> ▼kai_tcp_server について
>>>>>>>>>>> たけまるさん日記バージョンに下記の修正を入れました。
>>>>>>>>>>> ・behaviour 化
>>>>>>>>>>> ・Mod:handle_call に Socket を渡す
>>>>>>>>>>> ・{active, true} で listen 可能
>>>>>>>>>>>
>>>>>>>>>>> ▼テストについて
>>>>>>>>>>> ・make test 時に ./ebin を参照
>>>>>>>>>>>
>>>>>>>>>>> ・Coverage Analysis 対応の為、test/kai.coverspec 追加
>>>>>>>>>>> 現状、kai_tcp_server, kai_api, kai_memcache を直書きしています。
>>>>>>>>>>> 後で、make test コマンドで Makefile 内の SOURCES から生成したいと考えております。
>>>>>>>>>>> make に詳しい方のご助言希望。
>>>>>>>>>>>
>>>>>>>>>>> ・Coverage Analysis 対応の為、make 時に +debug_info を付加
>>>>>>>>>>> make test を実行しない場合であっても、強制的に erlc +debug_info になります。
>>>>>>>>>>> これも、make に詳しい方のご助言希望。
>>>>>>>>>>>
>>>>>>>>>>> ▼現状、認識している残作業
>>>>>>>>>>> テストの Coverage を上げる。
>>>>>>>>>>>
>>>>>>>>>>> 以上です。
>>>>>>>>>>>
>>>>>>>>>>> 2008/7/1 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>> {packet, line} とかのことはまったく気にしてませんでした．．
>>>>>>>>>>>>
>>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>>
>>>>>>>>>>>> 僕も 2 が良いように思いました．
>>>>>>>>>>>> {packet, line} に戻すことを指示するキレイな方法があるかなぁ．
>>>>>>>>>>>>
>>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>>
>>>>>>>>>>>> あんまり複雑になるようなら 3 にしてしまったほうがいいのかもしれないですね．
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2008/7/1 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>> 自分の才能の無さに絶望したので、お知恵を拝借させて下さい orz
>>>>>>>>>>>>>
>>>>>>>>>>>>> 下記、kai_tcp_server のコード片です。
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option) ->
>>>>>>>>>>>>> case gen_tcp:recv(
>>>>>>>>>>>>> Socket, Option:get(recv_length), Option:get(recv_timeout)
>>>>>>>>>>>>> ) of
>>>>>>>>>>>>> {ok, Data} ->
>>>>>>>>>>>>> case Mod:handle_call(Data, State) of
>>>>>>>>>>>>> {reply, DataToSend, State} ->
>>>>>>>>>>>>> gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>> {noreply, State} ->
>>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, Option);
>>>>>>>>>>>>> {setopts, SocketOptions, RecvLength, State} ->
>>>>>>>>>>>>> inet:setopts(Socket, SocketOptions),
>>>>>>>>>>>>> NewOption = kai_option:new(
>>>>>>>>>>>>> [
>>>>>>>>>>>>> {recv_length, RecvLength},
>>>>>>>>>>>>> {recv_timeout, Option:get(recv_timeout)}
>>>>>>>>>>>>> ],
>>>>>>>>>>>>> ?DEFAULT_OPT_PROP
>>>>>>>>>>>>> ),
>>>>>>>>>>>>> acceptor_loop(Socket, State, Mod, NewOption);
>>>>>>>>>>>>> {close, DataToSend, State} ->
>>>>>>>>>>>>> gen_tcp:send(Socket, DataToSend),
>>>>>>>>>>>>> gen_tcp:close(Socket);
>>>>>>>>>>>>> _Error ->
>>>>>>>>>>>>> gen_tcp:close(Socket)
>>>>>>>>>>>>> end;
>>>>>>>>>>>>> {error, Reason} ->
>>>>>>>>>>>>> exit({error, Reason})
>>>>>>>>>>>>> end.
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> たけまるさん版に改良を加え
>>>>>>>>>>>>> Mod:handle_call/2 に {setopts, SocketOptions, RecvLength, State} という戻り値を加えてみました。
>>>>>>>>>>>>> こうする事で、{packet, line} <-> {packet, raw} のオプション変更に対応しています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ※RecvLength あたりが美しくないですよね・・・
>>>>>>>>>>>>> ※まだ、kai_option を使っているのですが、これは後で別途相談を・・・
>>>>>>>>>>>>>
>>>>>>>>>>>>> この状態で、kai_memcache を途中まで修正してみたのですが
>>>>>>>>>>>>> put クエリ対応がカオスになってしまいました。
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> handle_call(Data, [{packet, line}] = State) ->
>>>>>>>>>>>>> dispatch(string:tokens(binary_to_list(Data), " \r\n"), State).
>>>>>>>>>>>>>
>>>>>>>>>>>>> dispatch(["set", Key, Flags, "0", Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>> {
>>>>>>>>>>>>> setopts,
>>>>>>>>>>>>> [{packet, raw}],
>>>>>>>>>>>>> Bytes,
>>>>>>>>>>>>> [{packet, raw}, {state, Key, Flags}]
>>>>>>>>>>>>> };
>>>>>>>>>>>>> dispatch(["set", Key, Flags, Exptime, Bytes], [{packet, line}] = State) ->
>>>>>>>>>>>>> {reply, "CLIENT_ERROR Exptime must be zero.\r\n", State}.
>>>>>>>>>>>>>
>>>>>>>>>>>>> handle_call(Value, [{packet, raw}, {state, Key, Flags}] = State) ->
>>>>>>>>>>>>> Data = #data{key=Key, flags=Flags, value=Value},
>>>>>>>>>>>>> case kai_coordinator:route({put, Data}) of
>>>>>>>>>>>>> ok ->
>>>>>>>>>>>>> {reply, <<"STORED\r\n">>, State};
>>>>>>>>>>>>> _Other ->
>>>>>>>>>>>>> send_error_and_close("Failed to read.", State)
>>>>>>>>>>>>> end.
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> 作りかけなので、上記は、下記のようなバグを持っています。
>>>>>>>>>>>>> ・<<"STORED\r\n">> した後に {packet, line} に戻していない
>>>>>>>>>>>>> ・Value の後に続く、<<"\r\n">> を受信しきっていない
>>>>>>>>>>>>>
>>>>>>>>>>>>> で、今後の対応として、下記の三つを考えております。
>>>>>>>>>>>>> １．このまま続ける。
>>>>>>>>>>>>> Mod:handle_call/2 に gen_tcp:send しつつ inet:setopts するモードを追加すれば
>>>>>>>>>>>>> このままいけそうな気がしています。カオスですが・・・。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ２．Mod:handle_call に Socket を渡してしまう。
>>>>>>>>>>>>> {packet, line} だけ、kai_tcp_server に任せ、複雑な事は Mod で行ってしまおうかと。
>>>>>>>>>>>>> 個人的には、これが一番良いかな？と思っています。
>>>>>>>>>>>>>
>>>>>>>>>>>>> ３．Mod に gen_tcp:recv や gen_tcp:send を完全に任せる。
>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624/1214315157
>>>>>>>>>>>>> これに近い感じです。（そのままは使いません）
>>>>>>>>>>>>>
>>>>>>>>>>>>> と言う事で、意見募集中です。
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>> では、諸々考慮しつつ、kai へ組み込んでみますね。
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> はい，ガンガン進めちゃってください．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 念のため、branch を作ります。
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> embed_tcp_server
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> と言う branch で、如何でしょうか？
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> それでもいいですし，kai/branches/cooldaemon/hoge/
>>>>>>>>>>>>>> のようにアカウント名でディレクトリを掘ったほうが気楽であれば，こっちでもいいです．
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>> おー、この方が素敵ですね！
>>>>>>>>>>>>>>>>> tcp_server.erl 用に behaviour を作っても良いかもしれませんね。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Kai に限定されない，汎用モジュールっぽくていい感じです :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> あと、kai の場合は、tcp_server.erl 二つ(api と memcache)起動する必要があるので
>>>>>>>>>>>>>>>>> supervisor 二重起動を許可しないといけませんね。
>>>>>>>>>>>>>>>>> （確認とってませんが、確か、同名の supervisor は起動できないハズ）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> そんな制約があるかもなのですね．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> そう言えば、TrapExit かどこかで
>>>>>>>>>>>>>>>>> application、supervisor、gen_server を
>>>>>>>>>>>>>>>>> 一ファイルに記述する方法が掲載されていました。
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> いろんな技があるのですねぇ．
>>>>>>>>>>>>>>>> 僕はそういうサイトを読み込めてないので，車輪の再発明をしてそうです．．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 今回の、tcp_server.erl は、supervisor と proc_lib が同居しているので
>>>>>>>>>>>>>>>>> module として持ち運びが簡単かなぁと思うのですが
>>>>>>>>>>>>>>>>> コード量によっては、分割した方が良い気もします。
>>>>>>>>>>>>>>>>> （今回のファイルサイズであれば、分割は不要だと思います）
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 今回も迷ったのですが，何となく一つのファイルにまとめてみて，そのままにしてあります．
>>>>>>>>>>>>>>>> 書きやすさ・読みやすさに合わせて分割してしまってください．
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 2008/6/25 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> これを読んで合点がいきました．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20080624
>>>>>>>>>>>>>>>>>>> こんな感じで、どうでしょうか？
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 素晴らしいです．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> せっかくなので，完全に OTP にしてみました．
>>>>>>>>>>>>>>>>>> 使いやすくなってるかは微妙．．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> たけまる / 続・Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>> http://teahut.sakura.ne.jp/b/2008-06-25-1.html
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Mochiweb 方式より、accept 待ちプロセスを複数持つ方式の方が
>>>>>>>>>>>>>>>>>>> シンプルでコード量が少ないですねぇ
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> そういう気がします．
>>>>>>>>>>>>>>>>>> 同時に accept できるというのは比較的新しい機能のようですね．
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2008/6/24 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> メール＆ブログのエントリを拝見致しましたが
>>>>>>>>>>>>>>>>>>>> たけまるさんと私の考え方は
>>>>>>>>>>>>>>>>>>>> 一致しているかなーと思います。
>>>>>>>>>>>>>>>>>>>> ※私が勘違いしているかも？
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Mochiweb もそうなのですが
>>>>>>>>>>>>>>>>>>>> accept した時点で、現在のプロセス数をインクリメントし
>>>>>>>>>>>>>>>>>>>> 最大接続数に達した時点で、accept を止めます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> プロセスが終了する度、EXIT メッセージが親に通達されるので
>>>>>>>>>>>>>>>>>>>> プロセス数をデクリメントします。
>>>>>>>>>>>>>>>>>>>> （accept ループを抜けていた場合は、再開）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> なんとなくですが
>>>>>>>>>>>>>>>>>>>> 私は、accept するプロセスをプーリングする方式の方が
>>>>>>>>>>>>>>>>>>>> 速度が出そうな気がしますけれど。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> ついでに、kai_api, kai_memcache のコードの共通化も可能です。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> で、両者の良いとこ取りを出来ないかと思い
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> と書いたのですが、これの説明が悪いので、もう少しだけ補足を書かせて下さい。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>> ここの Server Design のアスキーアートをベースに話をします。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> tcp_server_sup は、tcp_acceptor と tcp_client_sup を起動し監視下に置きます。
>>>>>>>>>>>>>>>>>>>> その際、tcp_acceptor を、最大接続数分 起動します。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 接続があると、tcp_acceptor は
>>>>>>>>>>>>>>>>>>>> tcp_client_sup に tcp_echo（kai_memcache） を起動しなさい！と
>>>>>>>>>>>>>>>>>>>> メッセージを送ります。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 接続時に spawn しているので tcp_acceptor を複数起動するメリットが
>>>>>>>>>>>>>>>>>>>> accept ループを出たり入ったりする処理を
>>>>>>>>>>>>>>>>>>>> 書かなくて良い点だけになってしまいますが・・・。
>>>>>>>>>>>>>>>>>>>> （単一プロセスのループ処理を、複数プロセスに置き換えているところが
>>>>>>>>>>>>>>>>>>>> Erlang っぽくて萌えるのですがｗ；）
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 死活監視と接続最大数は別の話だとは思いつつも
>>>>>>>>>>>>>>>>>>>> proc_lib の下に proc_lib や普通のプロセス(?) を配置すると
>>>>>>>>>>>>>>>>>>>> OTP の恩恵を受けられないので、何とかならないかなぁと思ってます。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> いやー、こういう話がないと、開発してる気分になれない気が（ｗ；
>>>>>>>>>>>>>>>>>>>> お気になさらずにー。
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> すいません，少し勘違いしていました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 今回やろうとしていたことは，同時接続数の制限です (という言い方をすれば誤解がなかったのか)．
>>>>>>>>>>>>>>>>>>>>> よく考えれば，
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - プロセスの生死を管理すること
>>>>>>>>>>>>>>>>>>>>> - 同時接続数を制限すること
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> これらは別の話ですね．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 僕がイメージしていたのは，つねに一定数のプロセスを起動しておいて，暇なやつにリクエストを処理させる
>>>>>>>>>>>>>>>>>>>>> (暇やつがいなければリクエストを待たせておく) という振る舞いでした．
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法だと，プロセスの死活監視はできるのですが，プロセス数が一定ではないので，同時接続数を制限することはできません．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cooldaemon さんの方法は，プロセスを増やしながら生死を管理するための高度な方法です．
>>>>>>>>>>>>>>>>>>>>> 今回の局面で使うには少し違うかも，という気がしています．
>>>>>>>>>>>>>>>>>>>>> 僕のイメージとは少し違ったのですが，有用な方法であることは間違いないので，どこかで役に立つと思います
>>>>>>>>>>>>>>>>>>>>> (まだ勘違いしてるかもしれないので，気づいた点がありましたら指摘してください＞＜)．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 詳しくはブログに書きました．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> たけまる / Erlang で Apache worker MPM っぽいこと
>>>>>>>>>>>>>>>>>>>>> http://teahut.sakura.ne.jp/b/2008-06-23-1.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> というわけで，混乱させてしまってすみません m(_ _)m
>>>>>>>>>>>>>>>>>>>>> これに懲りずにおつきあいくださいませ．
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> spawn のコストが高くなった時点で
>>>>>>>>>>>>>>>>>>>>>> acceptor をプーリングしておく方式に切り替える事も
>>>>>>>>>>>>>>>>>>>>>> 検討材料として残しつつ、作業を進めます。
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> その場合は、tcp_client_sup がプロセスの死活監視を行う事になります。
>>>>>>>>>>>>>>>>>>>>>> (名前は、kai_tcp_client_sup とかが良いでしょうか？)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> http://d.hatena.ne.jp/cooldaemon/20071024/1193193093
>>>>>>>>>>>>>>>>>>>>>>>> ↑この仕組みで汎用化してしまい
>>>>>>>>>>>>>>>>>>>>>>>> tcp_acceptor の箇所で接続数の制限を行うのは
>>>>>>>>>>>>>>>>>>>>>>>> 如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> はい，そんな感じです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> やろうとしていることは，『プログラミングErlang』14.1 の最後に書いてあることそのままです．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> | Erlang バージョン R11B-3 では，1つの待ち受け用ソケットに
>>>>>>>>>>>>>>>>>>>>>>> | 対して複数の Erlang プロセスが gen_tcp:accept/1 を呼び出すことが
>>>>>>>>>>>>>>>>>>>>>>> | できる．この機能を利用すれば，前もって生成しておいたプロセスのプー
>>>>>>>>>>>>>>>>>>>>>>> | ルを用意しておいて，その各プロセスを gen_tcp:accept/1 で接続待ち
>>>>>>>>>>>>>>>>>>>>>>> | 状態にしておくことができるので，並列サーバを作るのが簡単になる．(p.207)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 僕がどうするつもりだったかというと，わりと適当にしか考えてなくて，『プログラミングErlang』付録D に出てくる lib_chan_cs
>>>>>>>>>>>>>>>>>>>>>>> のように，accept 待ちのプロセスを指定した数だけ spawn しておけばいいかなくらいに思ってました．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> possibly_start_another(false, Listen, Active, Fun, max) ->
>>>>>>>>>>>>>>>>>>>>>>> case length(Active) of
>>>>>>>>>>>>>>>>>>>>>>> N when N < Max -> % worker 数が Max 未満なら
>>>>>>>>>>>>>>>>>>>>>>> New = start_accept(Listen, Fun), % accept 待ちプロセスを起動
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ただこの方法だと worker の生死管理を自分で書かないといけないので，cooldaemon さんの方法のがよさそうです．
>>>>>>>>>>>>>>>>>>>>>>> というわけで，いけそうなら sourceforge の tracker で自分にアサインしちゃってください．
>>>>>>>>>>>>>>>>>>>>>>> kai_api と kai_memcache がありますが，kai_memcache のほうがデバッグしやすい気がします．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ちなみに，プロセスプールを TODO に入れた理由は次のとおりです．
>>>>>>>>>>>>>>>>>>>>>>> いまの Kai は，毎秒数百リクエストを送りつけると負荷が高くなって，メンバシップの管理ができなくなり，クラスタが分解してしまいます．
>>>>>>>>>>>>>>>>>>>>>>> これを回避できるとしたら，API の受け付け数を制限するしかないかなと．
>>>>>>>>>>>>>>>>>>>>>>> 『プログラミングErlang』でも，この機能をトラフィックシェーピング (流量制御) と読んでますね．
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2008/6/23 masahito ikuta <coo...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon です。
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>- kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> こちらの作業内容を
>>>>>>>>>>>>>>>>>>>>>>>>> もう少し詳しく教えて頂いて宜しいでしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （何となく、参加できそうな気がしたので・・・）
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> とても細かい話で申し訳ないのですが・・・
>>>>>>>>>>>>>>>>>>>>>>>>> 現在、make すると src ディレクトリ配下に beam ファイルが出来てしまうので
>>>>>>>>>>>>>>>>>>>>>>>>> OTP っぽく ebin ディレクトリ配下に配置したいと思いますが、如何でしょうか？
>>>>>>>>>>>>>>>>>>>>>>>>> （autotools に対応する気力は無いのですが orz）
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2008/6/22 Takeru INOUE <tak...@gm...>:
>>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 6/19 にこのメールを送ったのですが，sourceforge の作業中だったから送られてないようなので (archive に表示されない)，再送します．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> ---------- Forwarded message ----------
>>>>>>>>>>>>>>>>>>>>>>>>>> From: Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>> Date: 2008/6/19
>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: 開発の進め方
>>>>>>>>>>>>>>>>>>>>>>>>>> To: kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 井上 (たけまる) です．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> きのうは勉強会に参加いただきありがとうございました．
>>>>>>>>>>>>>>>>>>>>>>>>>> お陰様で，面白い会になったと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> さて，開発の進め方についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> まず，発表で言ったように，kai_memcache から coordinator の機能を分離しておきます．
>>>>>>>>>>>>>>>>>>>>>>>>>> また，kai_version という空のモジュールを作っておきます．
>>>>>>>>>>>>>>>>>>>>>>>>>> これで，基本的なモジュール構成が固まるので，開発しやすくなると思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 次に，実装の順序についてです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 基本的には好きなところから実装してもらって構わないと思うのですが，次のようなのが他の部分への影響が少なく取りかかりやすいでしょうか (面白みも少ないけど)．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - ./configure
>>>>>>>>>>>>>>>>>>>>>>>>>> - test_server
>>>>>>>>>>>>>>>>>>>>>>>>>> - kai_store の永続化
>>>>>>>>>>>>>>>>>>>>>>>>>> - kai_api, kai_memcache のプロセスプール
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> チューニングの類 (特にトリッキーなコードを伴うもの) は後回しにしたいと思います．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> コミッタは 5-10名と多くないので，管理はゆるめで進めたいです．
>>>>>>>>>>>>>>>>>>>>>>>>>> 早い者勝ちで手を挙げた人が実装してみて，行き詰まったら ML などでヘルプを求めるというのでいいかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>>> 誰が取り組んでいるかを知るために，sourceforge の Tracker を使うべきかなぁ．
>>>>>>>>>>>>>>>>>>>>>>>>>> 適当にブランチを切って自由に進めてもらって，落ち着いたところで merge するというので大丈夫だろうか．
>>>>>>>>>>>>>>>>>>>>>>>>>> モジュールのインタフェースが変更されるときは気をつけないといけないけど (merge は僕がやったほうがいいのかも)．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> といったあたりについて意見を聞かせてください．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> # こういった開発者のための意識合わせ的なことは，Wiki にまとめて後で周知します．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> # うまく回り始めたら，僕は全体のコーディネートにまわるつもりです．
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>>>>>>>>>>>>>>>> It's the best place to buy or sell services for
>>>>>>>>>>>>>>>>>>>> just about anything Open Source.
>>>>>>>>>>>>>>>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> Kai-devel-ja mailing list
>>>>>>>>>>>>>>>>>>>> Kai...@li...
>>>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-devel-ja
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> cooldaemon
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> cooldaemon
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> cooldaemon
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> cooldaemon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Takeru INOUE <tak...@gm...>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> cooldaemon
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Takeru INOUE <tak...@gm...>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> Takeru INOUE <tak...@gm...>
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> Takeru INOUE <tak...@gm...>
>
--
cooldaemon
|