[ruby-dev:26345] Re: rb_gc_mark_threads spin

まつもと ゆきひろです

In message "Re: [ruby-dev:26343] Re: rb_gc_mark_threads spin"
    on Sun, 12 Jun 2005 22:53:42 +0900, Tanaka Akira <[e-mail]> writes:

|あるスレッドが終了した後、他のスレッドが IO 待ちだと、次に動作するスレッ
|ドが決めるのに select する必要がありますが、その select がブロックする
|と任意の長い時間存在することになります。[ruby-dev:26128] はそういうケー
|スです。つまり、少なくとも [ruby-dev:26128] が再現する環境では後者です。
|
|そして、select には fd_set が必要で、rb_fd_init 導入以降そこで GC が起
|こることがあります。そのときに curr_thread が環状リストから外れている
|ので rb_gc_mark_threads が無限ループになるというのが今回の原因です。

これは rb_gc_mark_threads でFOREACH_THREAD_FROM(main_thread) 
を使うことで対応した部分ですね。これで[ruby-dev:26312]で報告
されている無限ループは対処できてると思いますが、どうですか？

|えぇと、後からいろいろと思うところが出てきたのですが、まず
|        rb_thread_main_jump(ruby_errinfo, RESTORE_EXIT);
|というのをてきとうに他からコピーしてきてしまったんですが、ruby_errinfo
|を設定した覚えがないので参照するのはよろしくないように思います。

確かに。terminate_process()の中で行っているように

  rb_class_new_instance(2, args, rb_eSystemExit)

を使うべきでしょうね。

|また、そもそも signal は main thread に届くという仕様なので、届いた瞬
|間に偶然動いていたスレッドを遡って終了させてから main thread に伝播す
|るのではなく、直接 main thread に送るほうが適切だと思います。

おっしゃる通りで、rb_thread_interrupt()はそのつもりで書いて
ます。今回はrb_exit()という話ですから、どこかで「signalが届
いた瞬間偶然動いたスレッドを終了させてからmain threadに伝搬
させる」ようなコードがあるということですね。それは見落としで
すから、直す必要があります。どこでしたっけ(trap以外で)。

|さらに、trap で EXIT にすると任意のタイミングで終了させられるようなの
|ですが、これは危険ではないでしょうか。まぁ、これは安全な signal
|handling とからむので、そう単純な話ではありませんが。

それでもmain_threadでexitするべきでしょうね。ちょっと考えて
みます。trap_exec()をいつもmain threadで実行するようにすれば
良いのかなあ。

# とか言ってたら中田さんが実装してくれたりして。^^;;;

                                まつもと ゆきひろ /:|)