はじめてのにき

_ イベントvsスレッド

http://morihyphen.hp.infoseek.co.jp/log2/200809.html#091530

あー説得されるなぁ。 このへんは考えるたびに違う結論になる気がするんだよな。 今はスレッド派。 woさんと想定してる例が全然違う感じがして、 結局適材適所的なんじゃないかと思ったりとか。 一度イベント派vsスレッド派の宗教闘争とかするべきだな。

とりあえず前教えてもらった正反対の主張をはっておく。

http://www.spa.is.uec.ac.jp/~kinuko/survey/body/events-are-bad.html

で、この話で僕がとりあえず最初に想定するのは webサーバ的なサーバで、 サーバの main thread が accept した fd を 別スレッド以下 slave とでも呼ぶに渡すとかそういう。 で、そいうモデルだと slave から main の方に 送るデータってほとんど無いあたりで、 違いが出てくるのかなぁ。 データが密接に絡めが絡むほど スレッドの方が不利になってくるのは真だと思うし。

で少なくともこいうモデル考えてる時は、 状態遷移表とかきちんとやらんでも うやむやにしきれちゃうケースが多いんじゃないかなぁ…と思う。

とりあえずこっち系モデルで ぱっと思いつくイベントうざい例として、

void handleRequestSimple(int fd) {
  read(fd);
  // hogehoge
  write(fd);
}

とかいう関数をリクエストが来るたびに呼ぶとする。 スレッドの方は

threadLibrary.create(&handleRequest);

とかしてて(もちろん現実的には thread pool なんだろうけど)、イベントの方は

eventLibrary.register(&handleRequest);

とかしてる感じだとする。

hogehoge が簡単な処理なら良いんだけど、 例えば proxy みたいに他のサーバからデータ 取ってくるようなケースだとすると、 スレッドなら

void handleRequest(int fd) {
  read(fd);
  foo();
  requestAnotherServer();
  bar();
  write(fd);
}

とかそのまま書きゃいいわけだけど、 イベントの方だと、

void handleRequestDone(int fd) {
  bar();
  write(fd);
}

void handleRequest(int fd) {
  read(fd);
  foo();
  requestAnotherServerAsync(bind(handleRequestDone, fd));
}

とかになるのかな。 まずこの関数増やすとかうざいんだけど、 それはまぁ問題ないとして、 例えば bar がバグってた時に本当にうざいんだよな。 スタックトレースとか見ると、 スレッドの方は、

bar
handleRequest
thread_main

とかになるのかな。 で、イベントの方は、

bar
handleRequestDone
EventLibrary::loop
...
main

とかになって、これだと何がイヤだって言うと 誰が handleRequestDone を呼んだのかわかんなくなってるっていう点。 手続き的な思考に慣れてる身としては、 気持ち的には handleRequestDone は handleRequest が 呼んでるつもりだったんだけど、 それがスタックトレースに無くて、 バグを追跡しにくい、っていうような。

何かしら callback というのは書く方もイマイチだと思うけど、 少なくとも第三者によるコードの可読性を損ねるというのは ほぼ間違いないんじゃないかと思う。

まぁでもこのへんは僕のわかる範囲でも偏った議論で、 デバッガがイベントモデルサポートみたいなのを入れてくれればいいんじゃね、 スレッドはほどほどのサポートあるんだから不公平な比較だ、 みたいな話と、 スレッドは無限に作るわけにはいかない、っていう話がある。

後者の方はつまり、 thread pool に thread が えーとさっきの論文紹介によると10万スレッドあるとして、 いやそんだけあったら大丈夫だろ…って感じがするけど、 その10万全てがその全てが requestAnotherServer に使われてしまうと、 requestAnotherServer を伴わないような、 簡単な処理 handleRequestSimple とかをする余裕が あるのにできなくなってしまって、 結局イベントモデル的なものを併用しなくちゃいけなくなる、 っていう話。 いやまぁ10万スレッドあるなら大丈夫な気もするが…

あとまぁどうでもいいけど重要な話として、 10万スレッドもあるとデバッグが別の意味でムズいという話が。 つまりどれが重要なスレッドなのかさっぱりわからなくて、 デバッガなどでスタックトレース見る時にどのスレッド見ればいいのー的な。 まぁこれもデバッガおよびランタイムが賢くなればなんとかなるか。

あとまぁレースコンディションとかあると 再現しにくいバグが出うるっていう wo さんの指摘は その通りだと思うし、

あーうーんやっぱ適材適所的な感じなのかなぁ。 スレッドベースの GUI ライブラリとかあるのかな。 キーボードを待つスレッドとマウスを待つスレッドと… みたいなの。

ふーむ

(09:51)

_ イテレータとスレッド論争

http://twitter.com/kinaba/statuses/922906127

これ微妙に面白いなぁ本質的ではなさそうだけど 例えとしてはなんかよくわかる。

しかし考えるとすぐによくわからんくなるので、 一度俺はスレッドの明日を守る守護神であるという設定で wo さんととっくみあいが起きる程度の論争とかすべきなんだと思う。

まーでも適材適所くさい気がするなぁ。 僕がよく見るような、 単一の機能を提供してるようなサーバとか、 裏でなんかしつつユーザになんか見せる、とか その程度の単順なサーバだと たいていスレッドの方が良さげに思う。

あと上に書いたような、ユーザのリクエスト処理してる間に 時間かかる処理しなきゃなんないような、 つまるところプロキシサーバみたいな物体も 割とスレッドな物体じゃないかなぁと思う。 あとユーザが長時間セッションをはって コマンドを順々に叩いてくるような物体も、 手続き的に書けるって意味でまぁ嬉しいかな。

で、複雑に内部状態を変更しつつも 長時間かかる IO があるようなものはどうすればいいのだろうね…

あとそうだ。小さいものは貧乏症的な意味で thread 使いたくない。 sevilwm の ipc 部分は thread で書いた方がラクだったと思うけど、 そういう理由で select でやってる。

(23:56)

_ ここらで

• scheme の人が言及
• shiro さん降臨

というような流れがあると考えなくてすんで大変嬉しい。

(23:57)