From: Tanaka Akira Date: 2005-06-12T22:53:42+09:00 Subject: [ruby-dev:26343] Re: rb_gc_mark_threads spin In article <1118583170.298416.26464.nullmailer@x31.priv.netlab.jp>, Yukihiro Matsumoto writes: > curr_threadが THREAD_KILLED になっている状態(そんなに長くな > いはず)でたまたま割り込みがかかってしまった、という話なんで > したっけ。それともなんらかの事情でcurr_threadがTHREAD_KILLED > のままになる時期がかなり長い時間存在するってことですか。 > > 後者なら、それなりの対応を考えないといけませんが。 あるスレッドが終了した後、他のスレッドが IO 待ちだと、次に動作するスレッ ドが決めるのに select する必要がありますが、その select がブロックする と任意の長い時間存在することになります。[ruby-dev:26128] はそういうケー スです。つまり、少なくとも [ruby-dev:26128] が再現する環境では後者です。 そして、select には fd_set が必要で、rb_fd_init 導入以降そこで GC が起 こることがあります。そのときに curr_thread が環状リストから外れている ので rb_gc_mark_threads が無限ループになるというのが今回の原因です。 > これでコミットしてください。 えぇと、後からいろいろと思うところが出てきたのですが、まず rb_thread_main_jump(ruby_errinfo, RESTORE_EXIT); というのをてきとうに他からコピーしてきてしまったんですが、ruby_errinfo を設定した覚えがないので参照するのはよろしくないように思います。 また、そもそも signal は main thread に届くという仕様なので、届いた瞬 間に偶然動いていたスレッドを遡って終了させてから main thread に伝播す るのではなく、直接 main thread に送るほうが適切だと思います。 さらに、trap で EXIT にすると任意のタイミングで終了させられるようなの ですが、これは危険ではないでしょうか。まぁ、これは安全な signal handling とからむので、そう単純な話ではありませんが。 -- [田中 哲][たなか あきら][Tanaka Akira]