[ruby-dev:26348] Re: rb_gc_mark_threads spin

In article <[e-mail]>,
  Yukihiro Matsumoto <[e-mail]> writes:

> |> おっしゃる通りで、rb_thread_interrupt()はそのつもりで書いて
> |> ます。今回はrb_exit()という話ですから、どこかで「signalが届
> |> いた瞬間偶然動いたスレッドを終了させてからmain threadに伝搬
> |> させる」ようなコードがあるということですね。それは見落としで
> |> すから、直す必要があります。どこでしたっけ(trap以外で)。
> |
> |sigexit -> rb_exit -> terminate_process -> rb_exc_raise
> |という流れで、signal が到着したタイミングで動いていたスレッドで例外がおきます。
>
> これはtrapの話ですよね。それは認識しています。trap以外でその
> ようなケースを御存じですか、という話です。

trap 以外には知りません。

えぇと、話の流れがわからなくなってしまったので少し考えてみたのですが、
もしかして『今回はrb_exit()という話ですから』というところから考えると、
rb_exit は Kernel#exit とかからも呼ばれるからそっちからの流れでも問題
があると受け取ったんでしょうか。

もしそうだとすると、そんなことはありません。私が rb_exit に手を入れた
のは、sigexit から呼び出されていて eval.c にある最初の関数として選んだ
だけで、それ以上の意味はありません。実際、ruby_errinfo の参照を避けて
terminate_process で生成する例外オブジェクトを利用するために、
terminate_process を変更したほうがよかったかなぁ、と後から思ったくらい
で。

sigexit と rb_exit の間に関数をひとつ新設したほうが適切だったかも知れ
ませんね。

> えーと、「それでも...」というのを省略しないで書くと
>
>   完全に(or 十分に)安全なsignal handlingを実現するのは簡単で
>   はありませんが、それでもせめてtrap "EXIT" は main thread 
>   で直接 exit するべきでしょうね。完全ではないけど、少しはマ
>   シになるから。

マシになるかどうかについては疑いを持っています。

が、EXIT は最終的に終了することが目的である (ことがおそらく多い) 以上、
不都合には目をつむるというのはアリだと思います。たとえ SEGV だろうと終
了することには違いないですし。

> です。私の勘違いでなければ指摘されたのは「安全なsignal
> handling」の話ですよね。

えぇ。いつくるかわからず、遅延が必要だが遅延させすぎてはならない、とい
うあれです。EXIT に関しては、遅延させすぎる可能性よりは危険を受け入れ
て遅延しないというのもひとつの見識であろうと思うわけですが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]