From: Hidetoshi NAGAI Date: 2011-06-30T14:45:04+09:00 Subject: [ruby-dev:43998] Re: ThreadGroup#make_local_space! 永井＠知能．九工大です． From: Urabe Shyouhei Subject: [ruby-dev:43995] Re: ThreadGroup#make_local_space! Date: Thu, 30 Jun 2011 09:43:16 +0900 Message-ID: <4E0BC69B.6080507@ruby-lang.org> > 提案なのですが、たしかに永井さんの提案のほとんどの部分には共感できません > が、いくつかの機能は別にあってもいいと思うものもあるので、機能毎に分けて > 再提案されてはどうでしょうか。All or nothingだとどうかんがえてもnothing > のほうにならざるをえません。 All or Nothing だとは考えていませんので，確かに明確に分けた方が望まし いですね．分け方としては， ・thread queue ・make_local_space! ・その他 というところでしょうか． > > あくまでも Ruby の上での話です． > > さすがにパラダイムとしてのスレッドプログラミングを > > どうこうしようなどとという大それたことは考えておりません． > > これまではできなかった，あるいは余計な手間やコストがかかっていた処理を > > 楽に書けるようになれば，利用の機会も増えるのではないかとは考えています． > > この趣旨には頷けるものがありますが、 > > > 強化案のメソッド群は，過去に thread を使っていろいろとやっているときに > > 「こういうのがあればもっと積極的に ThreadGroup を使うのに」 > > と考えたものが中心となっています (「ついでに」というものが複数含まれて > > いるのも事実ですが)． > > そうした実例，具体例が不足しているという批判は， > > 少なくとも現時点で確かにそのとおりで，否定できせん． > > だいたい分かってきたのですけれども、「スレッドプログラミングを便利にす > る」から「ThreadGroupを便利にする」の間に理論の飛躍があるというふうに思 > います。べつにThreadGroupじゃなくてもスレッドプログラミングが便利になれ > ばいいでしょう? 「べつにThreadGroupじゃなくても」はその通りですね． 現在の Ruby において，thread 群の取りまとめ役として存在しているのは ThreadGroup ですから，ThreadGroup を土台に便利にすることを考えるのは 素直な流れと考えていましたが，それが飛躍でありもっと別の解を検討すべ きだとおっしゃるなら，確かに私の検討不足ということなのでしょう． それはそれとして，出来てほしいと思う (確かに「私が」ですが) が現状で はうまく書けないことを可能にする一案としての提示はしたつもりです． Module での実装や $SAFE の拡張でということであれば，具体的にどのよう な仕様でそれを達成するのかの案を示していただけると比較検討がやり易く て助かります． > > まぁ，Ruby の thread そのものが使われなくなるだろうということであれば， > > ThreadGroup の強化など無意味なこととなります． > > スレッドを積極的に使わなくしていこうとはあまり思っていませんが、 > Mutex#lockがmutexをロックしないまま起きてくるかもしれないというもっと根 > 本的な仕様上の問題がありますので、ThreadGroupに多少メソッドが増えよう > が、Rubyのスレッドが使い辛いことにはたいして影響を及ぼさないと思います。 これは Ruby の thread そのものの性質の話 (改善するしないも別次元の話) で，今，議論している内容との関係は薄いように思うのですが．．． > >> Moduleはそのためのものですからね。しかるに、Module#mixではなく、 > >> ThreadGroupに機能を追加する、なぜですか。なぜModuleではないのですか。 > > > > 実行単位である thread を固有環境の単位として考えているからです． > > 良い説明が出てこなくて悩んでいるのですが， > > Module への装備が言語環境のレベルで箱庭を用意するのに対し， > > ThreadGroup への装備は実行環境のレベルで箱庭を用意するとでも > > 言えばいいのでしょうか． > > うーん、良い説明が出てこないものはやはり良くないからではないかという疑問 > を提示せざるを得ませんね。 良い説明ではなくても，先の記述では伝わりませんか？ まぁ，伝わらないからそのようにおっしゃっているのでしょうけど．(^_^; > ちょっとやりたいことが見えてきません。make_local_space!のサンプルコード > は機能の解説にはなっていましたが、何がどう便利なのかが分かりませんでし > た。実際にこの機能を使うアプリケーションコードをどう想定しておられるのか > を提示していただいたほうがいいように思います。 おっしゃる通りですね．考えます． > > 固有環境を持った thread が sub thread を生成して処理を行うとき， > > sub thread は親 thread と共通の環境を引き継ぐことを求める場合が多い > > のではないかと思います． > > sub thread を生成するたびに固有環境のコピーを作るのは無駄ですので， > > デフォルトで引き継がれる ThreadGroup が固有環境情報を持っているのが > > 効果的だろうという考えです． > > ?? 作ったスレッドが親の環境を見ることができるのは「当然」だと思うのです > が。なぜわざわざThreadGroupが出てくるのですか? あ，ごめんなさい．わかりづらかったですね． この部分は，「実行単位である thread を固有環境の単位として考えているか らです．」を受けて書いている部分です． thread を固有環境 (ローカル空間) の単位と考えるのであれば，単純には固 有環境の情報を個々の thread に持たさせるということになるでしょう．しか し現実には，親子で共通の固有環境を用いることがほとんどでしょうから別々 に持たさせるのは無駄が多い．ThreadGroup に情報を持っておいてもらえばい いのではないかという，固有環境 (ローカル空間) の情報の保持場所について の話です． -- 永井 秀利 (nagai@ai.kyutech.ac.jp) 九州工業大学大学院情報工学研究院知能情報工学研究系知能情報メディア部門助教