大江戸Ruby会議01 "mission critical"なシステムでも使えるThreadの作り方
by Mayumi Emori on Apr 10, 2011
- 2,220 views
2011/04/10 (日) @深川江戸資料館レクホール
2011/04/10 (日) @深川江戸資料館レクホール
Accessibility
Tags
Upload Details
Uploaded via SlideShare as Adobe PDF
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 5
- Downloads
- 0
- Comments
- 3
- Embed Views
- Views on SlideShare
- 2,038
- Total Views
- 2,220
・’aborting’で時間がかかることがあるんですね。。。やってみないとわからない情報なんでしょうねえ。ありがとうございます。
・ThreadとSocketの両資源が残っているときにThread#killで回収しようとすると、Socket資源がリークしたりするので、Thread#raiseなどで先にSocketを別の方法で回収、というのが「お行儀のよい」方法だと思います。でも、bindだと資源はリークしないかもだし、きれいごと言ってるだけかもしれません。次の機会があればbindに気をつけてみます。 1 year ago Reply
・th_infosは、サンプルコードではHashのkeyにカウンタ-を使っているのですが、
複数プロセス × 複数スレッドの中で、固有の識別IDになる値をkeyにすることを想定しています。 →サンプルコードは分かりやすくするために、配列にした方がよかったですね。
・Thread#alive? だと、’aborting’ もtrueを返すので、異常なThreadを早く検知し、
再起動するために、statusを使っています。
statusの適切な更新が難しいというのは、知らなかったので、今後検討したいと思います…。
・Thread#kill については、Thread#alive? がfalse を返す場合ならよいのですが、
Thread#alive?がtrue(または、status が’run’ ) を返して、
Threadのループ内で更新させる情報(Slide内のThreadWatch#valid? )で
異常と判断された場合には、Thread#killは必要だと思うのですが、いかがでしょうか?
→各Thread で、socket をbind() しているような場合、
Threadを停止(kill)してからでないと、bind()エラーが出ていた記憶があります。 1 year ago Reply
・Thread#statusを’run’もしくは’sleep’で比較するのでなく、Thread#alive?を呼んでほしいです。JRubyのようなGILなし環境だと、statusを適切に更新するのが難しいので。。。
・今の構成だと、Thread#kill -> Thread#joinが絶対に刺さらないようにする必要があります。ensureでIO#closeとかやったり、ログ書き出し→その先のMutex取れず、などのパターンで刺さると、メインスレッドが止まるので。Thread#kill!だとリークする可能性もあるので、daemon系ではThread#kill系列は基本避けたほうがよいと思います。
・と、ここまで書いておいてなんですが、!th.alive?であれば、killとか意味ないかも? 1 year ago Reply