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

提案なのですが、たしかに永井さんの提案のほとんどの部分には共感できません
が、いくつかの機能は別にあってもいいと思うものもあるので、機能毎に分けて
再提案されてはどうでしょうか。All or nothingだとどうかんがえてもnothing
のほうにならざるをえません。

(06/30/2011 06:10 AM), Hidetoshi NAGAI wrote:
>> いいえ。Threadを束ねて使うという面ではむしろ現在のThreadGroupは配列より
>> も退化しており、積極的に忌避されます。少なくとも束ねたはずのスレッドが知
>> らぬ間にどっかに行ってしまうようなものを、私の感覚では束ねたとは言いません。
> 
> ThreadGroup#enclose は束から逃さないためのものですよね．
> 終了した thread が勝手に消えることをおっしゃっているのであれば，
> それは利点でもあり欠点でもあるでしょう．

利点は見えてきませんが、ここではThreadGroupが「配列とたいして変わらな
かった」のではなく、配列では普通に実現できる、死んだ水子の歳を数える行為
が不可能であることが認識されればOKです。thread_queueが最適な解かはともか
く、策を用意したということは永井さんとしてもこの点に思うことがあったとい
うことでしょう。

> あくまでも Ruby の上での話です．
> さすがにパラダイムとしてのスレッドプログラミングを
> どうこうしようなどとという大それたことは考えておりません．
> これまではできなかった，あるいは余計な手間やコストがかかっていた処理を
> 楽に書けるようになれば，利用の機会も増えるのではないかとは考えています．

この趣旨には頷けるものがありますが、

> 強化案のメソッド群は，過去に thread を使っていろいろとやっているときに
> 「こういうのがあればもっと積極的に ThreadGroup を使うのに」
> と考えたものが中心となっています (「ついでに」というものが複数含まれて
> いるのも事実ですが)．
> そうした実例，具体例が不足しているという批判は，
> 少なくとも現時点で確かにそのとおりで，否定できせん．

だいたい分かってきたのですけれども、「スレッドプログラミングを便利にす
る」から「ThreadGroupを便利にする」の間に理論の飛躍があるというふうに思
います。べつにThreadGroupじゃなくてもスレッドプログラミングが便利になれ
ばいいでしょう?

> まぁ，Ruby の thread そのものが使われなくなるだろうということであれば，
> ThreadGroup の強化など無意味なこととなります．

スレッドを積極的に使わなくしていこうとはあまり思っていませんが、
Mutex#lockがmutexをロックしないまま起きてくるかもしれないというもっと根
本的な仕様上の問題がありますので、ThreadGroupに多少メソッドが増えよう
が、Rubyのスレッドが使い辛いことにはたいして影響を及ぼさないと思います。

>> Moduleはそのためのものですからね。しかるに、Module#mixではなく、
>> ThreadGroupに機能を追加する、なぜですか。なぜModuleではないのですか。
> 
> 実行単位である thread を固有環境の単位として考えているからです．
> 良い説明が出てこなくて悩んでいるのですが，
> Module への装備が言語環境のレベルで箱庭を用意するのに対し，
> ThreadGroup への装備は実行環境のレベルで箱庭を用意するとでも
> 言えばいいのでしょうか．

うーん、良い説明が出てこないものはやはり良くないからではないかという疑問
を提示せざるを得ませんね。

> safe level は thread や block のような実行環境寄りに設定されるものです
> ので，動的に変更可能な枠組でなければどこかで無理が出るように思います．
> もちろん Module において binding よる変更は可能ですが，
> 実行環境としての binding の完全移行を行うのは無理矢理感が漂います．
> 例えば実行中の thread が自身の土台たる binding を変更可能にするのは
> 言語仕様として無茶であるように思います．
> そうでなければ module_eval や binding を指定しての eval などによるか，
> 新たな binding で thread を生成して自分は死ぬかのようなことになるので
> はないでしょうか．
> 前者は一時的な変更にしかなりませんから，元の実行環境に戻ってしまいます．
> 後者は新たに実行し直しているわけですから，「移行」とは違いそうです．

ちょっとやりたいことが見えてきません。make_local_space!のサンプルコード
は機能の解説にはなっていましたが、何がどう便利なのかが分かりませんでし
た。実際にこの機能を使うアプリケーションコードをどう想定しておられるのか
を提示していただいたほうがいいように思います。

> 固有環境を持った thread が sub thread を生成して処理を行うとき，
> sub thread は親 thread と共通の環境を引き継ぐことを求める場合が多い
> のではないかと思います．
> sub thread を生成するたびに固有環境のコピーを作るのは無駄ですので，
> デフォルトで引き継がれる ThreadGroup が固有環境情報を持っているのが
> 効果的だろうという考えです．

?? 作ったスレッドが親の環境を見ることができるのは「当然」だと思うのです
が。なぜわざわざThreadGroupが出てくるのですか?

Thread.start(1) {|x|
  Thread.start(2) {|y|
    Thread.start(3) {|z|
      puts x, y, z
    }
  }
}

2と3に共通の処理を書きたければ当然1でやりますよね?