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

最初に繰り返しておくのですがThreadPoolを強化しようということ自体にはむし
ろ賛成です、ただ、どの向きに向かって強化するのかがよく分からない。

なんにでも使えますは大抵の場合、なんにも使えませんよ。

(06/28/2011 03:15 PM), Hidetoshi NAGAI wrote:
>> 過去に若干の調査を行った結果、Threadを束にして操作したいという用途には
>> real world examplesが少なすぎて、いまいちです。
> 
> 基本的には束ねるものでしょうね．
> これまでは機能が少なすぎて，sub thread が自動的に含まれることを除き，
> thread を array に入れて管理するのとたいして変わらなかった，
> それゆえ，わざわざ使う気にもならなかったというように思います．

いいえ。Threadを束ねて使うという面ではむしろ現在のThreadGroupは配列より
も退化しており、積極的に忌避されます。少なくとも束ねたはずのスレッドが知
らぬ間にどっかに行ってしまうようなものを、私の感覚では束ねたとは言いません。

> ThreadGroup の機能強化により，ThreadGroup というものの活用の幅を広げ，
> ひいては thread 活用プログラミングの幅も広げられないかというのが趣旨です．
> 「そうは見えない」というのであれば，それは私の力不足ということです．

これは意欲的でよいと思いますが、もう少し具体的になるとなおよいです。ス
レッドプログラミングはパラダイムとしてははるか四半世紀前には存在していた
わけです(Mach microkernel)。今更どう広げようと? メソッド用意しとけば勝手
に広がるというのはさすがに目論見が甘いので、そうは思っておられないので
しょうが...

> 例えば thread pool として使うにしても，
> 処理を queue で渡して pool のいずれかの thread を起こすというのでは
> ThreadGroup のありがたみなどはありません．
> 監視する能力が弱いため，thread の状態変化に高い即応性を持たさせるためには
> polling したり，対象 thread ごとに１個の専用監視 thread を用意したり
> する必要があります．

これはその通りと思います。

> ThreadGroup オブジェクトに持たせようとする thread_queue は，
> thread 群の監視能力の強化を図るという意味合いがあります．
> thread pool コントロールの主導権を監視側に移すことが可能となります．
> 例えば thread 群が処理能力差のある別マシンに処理依頼をする場合でも
> 各 thread が処理完了に要した時間を監視し易くなりますから，
> スケジューリングもより緻密にできるかもしれません．

これは本当にThreadGroupを用いて実現する機能ですか?
たとえばスレッドが処理に要した時間をどこかに持っておくとすれば、当然その
スレッド自信が知っているのが自然と思いませんか? なぜThreadGroupをわざわ
ざ用意する必要があるのです?

> 自分で thread_queue を作って似たことを実現することもできますが，
> thread_queue への投入を ruby 本体の thread 管理に組み入れることで，
> 予期せぬ trouble で落ちた thread でも早くに低コストで拾えると思います．

これはキューを作るならという前提で、正しいでしょう。

> 関数的メソッドも使っているような普通の Ruby スクリプトを
> 環境汚染することなくそのまま動かせる環境が欲しいと考えています．
> スクリプトを無名モジュールで wrap して実行する場合，
> 関数的メソッドの定義はうまく機能しません．
> 関数的メソッドは Object クラスに定義されてグローバルに環境を汚染するため
> 禁止されても仕方がない存在ですが，使えた方が嬉しいのは確かです．
> 
> # 先のサンプルスクリプトには含んでいませんが，
> # ThreadGroup#make_local_space! は関数的メソッドについても
> # 有効空間を限定できますので，良かったらお試しください．
> 
> 既存のクラスに対するメソッド追加もしばしば行われますが，
> これもグローバルな変更になりますから禁止されるべきものとなります．
> safe level の問題以外のケースでも，定義が干渉し合うライブラリ等を
> 同時に使いたいという場合も同様の問題を含んでいます．

たとえば似たような問題意識としてclassboxとか呼ばれるものがあって、すでに
trunkにはModule#mixという機能が入っているわけですが、ご存知でしたか? メ
ソッドの可視性の変更をModuleで実現するというのはきわめて自然な発想です。
Moduleはそのためのものですからね。しかるに、Module#mixではなく、
ThreadGroupに機能を追加する、なぜですか。なぜModuleではないのですか。

> これらの問題のすべてを safe level の拡張で対処できるとは思えません．
> 仮に safe level からのアプローチで解決を図るとしても，
> ThreadGroup が管理単位となって make_local_space! のようなものが
> 必要になるだろうと予想します．

なぜですか。

> ならば，safe level と無関係に有効に使いうる make_local_space! を実装し，
> それと組み合わせて safe level の機能強化を考えるのも不自然とは思えません．

いいえ不自然です。なぜThreadGroupにそのような機能が必要ですか?