永井@知能.九工大です.

From: KOSAKI Motohiro <kosaki.motohiro / jp.fujitsu.com>
Subject: [ruby-dev:43979] Re: ThreadGroup#make_local_space!
Date: Tue, 28 Jun 2011 16:07:56 +0900
Message-ID: <4E097DC3.9070004 / jp.fujitsu.com>
> 若干まとまっていない感がありますが、わたしが今いだいている印象をダンプ
> させてください。どうも議論が進んでいないというか、このまま放置していても
> マージする流れにいかないんじゃないかな。という疑念がぬぐえないといいますか。。

反応の乏しさは,皆さんが現状に特に不満を持っていない
(多分,使っていないので困っていない) ことを物語っているのだと思います.

> たとえばJavaだと、今のRubyと同じく非常にプアなThreadGroupクラスがありますが、
> 現状のThreadGroupを積極的に使ってるケースも、それを拡張したいと思っている
> ユーザグループもあんまり心当たりがなかったりまします。
> なので、Javaでは不要だけどRubyでは必要となる理由はなんだろう。というのが
> 最初に抱いた疑問です。

実際に不便に感じていたことが発端ではあるのですが,
私が変り者ってことなんでしょうねぇ...(^_^;

> 次にたいへん遺憾ながらRubyにおいてthread 並列の未来は暗いんじゃないかと
> 思ってます。GVLがあるかぎり並列度があげようがないですから。
> で、たとえばプロセス並列とかMVMにとか走ってしまうと、やっぱり今回の
> 強化はあまり役に立たないのではないかと思えます。

1プロセスの Ruby only ではそうなのかもしれません.
複数の計算サーバに処理を分散して依頼する場合は話が変わってくると思います.

> なので、議論の出発点を「現状xxが出来ない」ではなく「yy出来るようにすると
> zzさんが嬉しい」といった視点から説明していただけると、(わたしの)理解が
> 容易になるのではないかと思うのですが、どうでしょうか。

改善案の頭の方でつらつらと書いていたことは,
実際に不便に思っていた内容だったのですが...

工夫次第で他に代行する手段があるケースも多いことは認めますが,
なんで ThreadGroup のようなモノがあるのに
自分で面倒なことをしなければならないのかと感じていました.

例えば,ものすごく特赦なケースで申し訳ないのですが,
ローカル空間は,Tk の WidgetDemo のようなものでは非常に嬉しいです.
WidgetDemo では学習支援機能としてデモスクリプトのソースを表示して,
それを編集した上で実行することができますが,
その際,関数的メソッドが使えないことや環境汚染されうることが問題で,
制約付きの不完全なものにしかなりませんでした.
当時,どうにかならないかとあれこれ考えてはみたのですが,
結局は Ruby 本体に手を入れる以外には解決策が見出せず,諦めました.

> あと、グループに対して出来る操作が増えると、ThreadGroup単位で排他制御が
> 必要になるので、GVLが存在しないJRubyあたりのパフォーマンスに影響を与えるのでは
> ないかという懸念があります。杞憂だといいのですが。

これについてはなんとも.
メソッド空間については登録の際のみに lock すればいいのではないかと
思っていますが,違いますかね?
だとしたら,そこまで大量にメソッド登録処理を繰り返すというのは
あまり考えなくてもよさそうなので,影響は小さいように感じます.

> あと、最後にひとつだけ付け加えるならtkが必要としている機能追加があるなら、たぶん
> 僕は賛成します。GUIはマルチスレッドが必要になるケースがあり、プロセス並列で
> 代替できないことは理解可能なので。

処理を書くのが楽になる部分はありそうなのですが,今は何とも言えません.

# 既存の機能の範囲で実装することばかりを考えてきたため,
# 逆はすぐには思い付きません.ごめんなさい.

コンテナとなるウィジェットに thread group を割り当てて…という企みも
なくはないですが,まだ朧ろげなプランです.
-- 
永井 秀利  (nagai / ai.kyutech.ac.jp)
九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教