シングルスレッド性能は2.じゃなくて3.
naruse
440
2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない（し、作ったつもりでもバグってるに決まってる）
3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる
-上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 2. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。
+上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。
結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。
すでに回答がついてるのと、まつもとさんや、ささださんが既に詳細に書かれていますが、
理由は大きく3つありまして、
- 現在の CRuby が (C レベルで) スレッドセーフではない
- 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない（し、作ったつもりでもバグってるに決まってる）
- 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる
上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。
結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。
すでに回答がついてるのと、[まつもとさん](http://www.rubyist.net/~matz/20070913.html)や、[ささださん](http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview38.html)が既に詳細に書かれていますが、 理由は大きく3つありまして、 1. 現在の CRuby が (C レベルで) スレッドセーフではない 2. 現在、そして将来の C 拡張ライブラリは (きっと) スレッドセーフには作られない（し、作ったつもりでもバグってるに決まってる） 3. 上記の対策でロックを随所に入れると、シングルスレッド性能が落ちる 上記 1. の具体例としては、まず正規表現実装である鬼車/鬼雲は現在 thread unsafe で入れています。コンパイルオプションで thread safe にはできるんですが、すると 3. の通りシングルスレッド性能が落ちます。ハッシュ実装である st も thread unsafe なのでロックしないと最悪 SEGV します。 結局、akr さんの仰られているとおり、単純になくすとレースコンディションってレベルではすまず SEGV してしまうし、頑張ってなくしても C 拡張ライブラリがあるからそこで SEGV するだろうって話になるので、 C 拡張ライブラリとの親和性をとてもとても重視している CRuby というプロダクトのデザイン上の決定としては、GVL を外すという判断はあまり簡単ではありません。