[ruby-dev:43996] Re: ThreadGroup#make_local_space!

> 永井＠知能．九工大です．
> 
> From: KOSAKI Motohiro <[e-mail]>
> Subject: [ruby-dev:43979] Re: ThreadGroup#make_local_space!
> Date: Tue, 28 Jun 2011 16:07:56 +0900
> Message-ID: <[e-mail]>
>> 若干まとまっていない感がありますが、わたしが今いだいている印象をダンプ
>> させてください。どうも議論が進んでいないというか、このまま放置していても
>> マージする流れにいかないんじゃないかな。という疑念がぬぐえないといいますか。。
> 
> 反応の乏しさは，皆さんが現状に特に不満を持っていない
> (多分，使っていないので困っていない) ことを物語っているのだと思います．

ええと、はい。正直もうしますと僕自身はJavaでもRubyでもThreadGroupを
ありがたいと思ったことは一度も無かったりします。

> 
>> たとえばJavaだと、今のRubyと同じく非常にプアなThreadGroupクラスがありますが、
>> 現状のThreadGroupを積極的に使ってるケースも、それを拡張したいと思っている
>> ユーザグループもあんまり心当たりがなかったりまします。
>> なので、Javaでは不要だけどRubyでは必要となる理由はなんだろう。というのが
>> 最初に抱いた疑問です。
> 
> 実際に不便に感じていたことが発端ではあるのですが，
> 私が変り者ってことなんでしょうねぇ．．．(^_^;

ああ、いやいや、そういう含みをもたせる意図はまったくありませんでした。
わたしがレビューで毎回ユースケースを聞くのは一種の職業病といいますか、
そういう開発文化に普段身をおいているので、ついつい出てしまうだけなんです。
他意はありませんでした。すいません。

ただ、ひっじょぉぉぉに申し訳ないのですが、私のレビュー能力はデザインの善し悪しを
見る能力にはまったくもって欠けていて、requirement とマッチしているかどうか
でしか見れないので、このパッチのレビューはかなりギブアップ気味です。卜部さんが
詳しく見てくれているようなので、しばらく静観させてください。


>> 次にたいへん遺憾ながらRubyにおいてthread 並列の未来は暗いんじゃないかと
>> 思ってます。GVLがあるかぎり並列度があげようがないですから。
>> で、たとえばプロセス並列とかMVMにとか走ってしまうと、やっぱり今回の
>> 強化はあまり役に立たないのではないかと思えます。
> 
> １プロセスの Ruby only ではそうなのかもしれません．
> 複数の計算サーバに処理を分散して依頼する場合は話が変わってくると思います．

あれ。私は逆に考えていました。
たとえばHPCだとOpenMP（スレッド並列）、MPI（プロセス並列）が並列化のメジャー
どころだと思うのですが、計算サーバが複数存在する場合は事実上MPI一択です。
プロセス並列(≒データは通信APIで陽に送受信する必要がある）モデルですと、
通信相手が同一計算にいる場合でも、異なる計算機にいる場合でも、同一処理で
出来てしまうから。

なので、永井さんの主眼はGUI的な領域とかなのだろうかと勝手に想像してました。
いやはや、はやとちりで申し訳ないです。

>> なので、議論の出発点を「現状ｘｘが出来ない」ではなく「ｙｙ出来るようにすると
>> ｚｚさんが嬉しい」といった視点から説明していただけると、（わたしの）理解が
>> 容易になるのではないかと思うのですが、どうでしょうか。
> 
> 改善案の頭の方でつらつらと書いていたことは，
> 実際に不便に思っていた内容だったのですが．．．
> 
> 工夫次第で他に代行する手段があるケースも多いことは認めますが，
> なんで ThreadGroup のようなモノがあるのに
> 自分で面倒なことをしなければならないのかと感じていました．
> 
> 例えば，ものすごく特赦なケースで申し訳ないのですが，
> ローカル空間は，Tk の WidgetDemo のようなものでは非常に嬉しいです．
> WidgetDemo では学習支援機能としてデモスクリプトのソースを表示して，
> それを編集した上で実行することができますが，
> その際，関数的メソッドが使えないことや環境汚染されうることが問題で，
> 制約付きの不完全なものにしかなりませんでした．
> 当時，どうにかならないかとあれこれ考えてはみたのですが，
> 結局は Ruby 本体に手を入れる以外には解決策が見出せず，諦めました．

この件だとうれしいだろうな。というところまでは同意します。
ちょっと細部の質問になってしまうのですが、この件だとthread終了とともに
thread local scopeのメソッドが消えてくれるのが利点であるかのように読めるのですが
make_local_space! の主目的はそのようなものであると理解してよろしいでしょうか。


>> あと、グループに対して出来る操作が増えると、ThreadGroup単位で排他制御が
>> 必要になるので、GVLが存在しないJRubyあたりのパフォーマンスに影響を与えるのでは
>> ないかという懸念があります。杞憂だといいのですが。
> 
> これについてはなんとも．
> メソッド空間については登録の際のみに lock すればいいのではないかと
> 思っていますが，違いますかね？
> だとしたら，そこまで大量にメソッド登録処理を繰り返すというのは
> あまり考えなくてもよさそうなので，影響は小さいように感じます．

登録の際のみに lock するだけならパフォーマンス的には問題ないという
点には同意します。
また、あれから考え直しまして、GVLがないモデルだとどうせ普通の
define_method vs メソッドコールとかでもlockが必要なので、追加ロックは
いらないような気がしてきました。よって、この件は取り下げさせてください。


>> あと、最後にひとつだけ付け加えるならtkが必要としている機能追加があるなら、たぶん
>> 僕は賛成します。GUIはマルチスレッドが必要になるケースがあり、プロセス並列で
>> 代替できないことは理解可能なので。
> 
> 処理を書くのが楽になる部分はありそうなのですが，今は何とも言えません．
> 
> # 既存の機能の範囲で実装することばかりを考えてきたため，
> # 逆はすぐには思い付きません．ごめんなさい．
> 
> コンテナとなるウィジェットに thread group を割り当てて…という企みも
> なくはないですが，まだ朧ろげなプランです．

なるほど。