ruby-dev

(2012/11/11 8:13), KOSAKI Motohiro wrote:
>> 　signal 用 thread を用意しておくと，deadlock 検出が殆どうまく行かなくな
>> るような気がするので，やっぱなしでいいかなぁ．いや，trap handler が定義
>> された瞬間に signal 用 thread を用意してやるのは悪くない気もする．
>> が，2.0.0 向けじゃないですな．
> 
> trap handlerを使うケースはもともとdeadlock検出はちゃんと動いていないのでこれ以上悪化するかなあというのが疑問だったり。
> あと、わたしはsignal用threadはtrap
> handler処理専用スレッド的なものをイメージしていたので、スレッド作成タイミングで挙動が変わるとは思っていなかった

　私もそういうイメージですが，「スレッド作成タイミングで挙動が変わるとは
思っていなかった」というのはどういう話でしょうか．下記の擬似コード参照．

> 現在の実装は thread->trap_enabled というフラグを追加し、fptr->write_lockをとるときにこれを disableに変えてしまう。
> そして、RUBY_VM_CHECK_INTS()で trap_enabledが０のあいだは、たとえ
> thread->interrupt_flag が非０でもtrap handlerを呼び出さない
> （今気づいたけど、添付したパッチは thread->interrupt_flagの 0x2以外も無視してるのでよくないですね。なおさないと）
> 
> この方針だと
> 
> ・fptr->write_lockだけが特別扱い。もともとrubyには見えてないこっそりロックだから挙動を変えても非互換ではない
> ・stdoutへのIOはすべて許される
> ・pipeへのwriteはwrite_nonblockを使うか、読み出し側をサブスレッドにしないとIOでブロッキングして刺さることはありえる（現状どおり）
> ・trap handler とmain threadの両方で mutex classを使った場合は、deadlock検出で死ぬことはありうる（現状どおり）
> 
> という感じ
> focusが trap { puts "hoge" } を救うことに集中してるバンドエイドパッチ。

　ちょっと大げさな気がするけど，まぁいいのかなぁ．

>> 　やはり根本的な解決策は，下記のような感じでしょうか．
>>
>> (1) trap ハンドラを設定すると，signal が配送されるのをまつ待機 thread を
>> 生成する (signal thread と呼称する）
>> (2) trap ハンドラがすべて削除されると，その thread は削除される
>> (3) trap ハンドラ内での全ての例外は main thread へ Thread#raise される
>>
>> でしょうか．
> 
> わたしのイメージはそんな感じ
> 
> 
>> てきとーに用語を定義しないでフィーリングで読んでもらうと，こんな感じ．
>> スレッドセーフじゃないのはご愛敬．
>>
>>   def trap(sig, &block) # 面倒なので cmd は略
>>     if block
>>       @@trap_handlers[sig] = block
>>       @@signal_thread = Thread.new{
>>         until @@trap_handlers.empty?
>>           sig = sigwait()
>>           begin
>>             @@trap_handlers[sig].call(sig)
>>           rescue CheckTrapHandler
>>             # ignore
>>           rescue Exception => e
>>             main_thread.kill(e)
>>           end
>>         end
>>       }
>>       end unless @@signal_thread
>>     else
>>       @@trap_handlers.delete(sig)
>>       @@signal_thread.raise(CheckTrapHandler) if @@signal_thread
>>     end
>>   end
>>
>>
>> 　半年くらい早くからこの議論をしていれば，こんなふうに変えるとすっきりし
>> たんじゃないかと思います．2.0.0 ではどうしますかねぇ．

　実装もこんな感じで同意でしょうか．

　もう，いっそいろいろ面倒なんで，変えちゃう？　遠藤さんが ok っていった
ら変えてもよさそうだが，ちょっと大きすぎるかなぁ．


>>>>> ・そもそもトラップからthrowして制御を戻すのは合法か？
>>>> 感覚的なことしか言えなくて申し訳ないのですが、これはさすがに無しじゃないでしょうか。
>>>
>>> だれか stackoverflowに書き込みできる人はあれにレースがあるよ、動かないよとコメントしてあげてください。
>>> 急遽アカウント作ったものの作りたてのアカウントではコメント書き込みできないみたい
>>
>> 　現在，たまたま出来ちゃうのがねえ．
> 
> 現状すでに何回かに一回はぎゃっとなるというコードしか書けない状態なので、throwも非同期になげるようにしても自体はあんまり悪化しないのでは。というあまり根拠のない予感があったり。だって、いま動いてないんだもん。

　今動いていない，というのは「タイミングによっては動かない場合がある」と
いう意味でいいでしょうか．私の主張は，「タイミングによっては動く場合があ
る」，しかも「動くタイミングが殆どである」という現状認識です．

> またはtrap handlerからthrowしたときに常にエラーになるようにエラーチェックを強化するというのも、何回かに一回失敗するよりかは親切なので、許される方針という認識

　それは同意．

-- 
// SASADA Koichi at atdot dot net

Thread

Prev Next

In This Thread

Prev Next