[ruby-dev:46644] Re: [ruby-changes:25810] kosaki:r37867 (trunk): * thread.c (rb_mutex_trylock, rb_mutex_unlock, mutex_sleep):

> Mutex#lock とかを，trap handler 中で出来ない，ってのは，すみません，どの
> 辺の話でしたっけ．

[ruby-dev:46434] とかで議論したときに、当分
trapからmutexが使えない制限は直さないということだったので、メージ的に例外投げるようにしました


> ruby-spec がこれで落ちているので気がつきました．
> すみません，これってそういうものでしたっけ．
> ちょっと，大きすぎるように思いまして．

関係あるかどうかわかりませんが、ささださんがircでtry_lockで落ちたと発言したログが残っていたので try_lockだけ例外出さないように変えました。
try_lockはdeadlockしないので。


> main thread と trap handler 中で競合が発生する（デッドロックになる）のは
> わかるんですが．
>
> ちょっとした回避策ですが，
>
> (1) main thread がロックを保持している
>     時のみ，Mutex#lock が例外を発生させる
>
> というのはどうでしょうか．これによって，
>
> (a) trap 内で完結する lock はちゃんと動く
>   （trap 内で unlock しない奴は死ねばいい）
>
> (b) sub-thread で lock している奴は，trap 内で待つことができる
>
> と出来ると思います．いかがでしょうか．

２つの理由から好きではありません。1) mutexがlock ownerを保持しているのが議論の前提になっているが、deadlock
detectionがない実装ではないではたぶん保持していないであろう
２）それではダメなプログラムを書いた時に、テストで通って本番で落ちるという最悪の結果になってしまい、deadlockからたいして好転していない

私の考えだと例外はプログラムが間違っていると教えて上げるためにあげているので、テストした時にうっかり通ってしまうような条件はあまり好きではなく、一般的にはレースしてそうなら例外という条件もあまり好きではありません。

どうせ、deadlockする制限がはずれたら例外上がらなくするつもりだったので、この変更全体をrevertするのもありですが、そもそもdeadlockしてうれしい人はいるんですかね


> ちなみに，POSIX thread はどうなってるんでしたっけ．

trylockも含め、すべてsignalハンドラで使うと動作する保証はありません