From: Hidetoshi NAGAI Date: 2007-01-29T16:40:56+09:00 Subject: [ruby-dev:30205] Re: YARV の thread について 永井＠知能．九工大です． 回答をありがとうございます． From: SASADA Koichi Subject: [ruby-dev:30202] Re: YARV の thread について Date: Mon, 29 Jan 2007 10:27:56 +0900 Message-ID: <45BD4033.6040208@atdot.net> > 　一応、model 3 については試作したものがあります。あとは外圧（やっぱり並 > 列に動かないとなぁ、とか）と皆のやる気（一人でやるにはちょっとつらい）や > リソース（どっかの会社によって取り組むとか）によるかと思います。 > > 　model 1 は、これも外圧（ネイティブスレッドうぜーよ！　という声）による > かと思います。こっちは現在も出来ていることから、もしかしたら少しがんばれ > ば対応できるかも、というところです。 model 1 はこれまでの Ruby の thread とほぼ同じと 考えてよいのですよね？ コンパイル時に，指定された Thread model がどれであるかを 判定するマクロ定数は用意されますか？ できればスクリプトからも Thread model の確認ができた方が 嬉しいのですが．．． # tcltklib の場合，model 1 であれば従来の戦略を取らねばならないし， # model 2 or 3 であれば新しい戦略をとらねばならないもので． > > * 組み込むライブラリ側で新たな native thread が作成された場合， > > その native thread から Ruby を呼ぶことは可能ですか？ > > 不可能ではない場合，どのような処理を先に呼んでおく必要がありますか？ > > 　現状では不可能です。 > > 　あんまり対策は考えていないんですが、そういう API を用意することは可能 > です。その際は、ちょっと面倒な制約が入るかもしれません。 > > > > * ライブラリ側で作成された native thread が並列動作をしようとする場合， > > 注意すべきことはどのようなことでしょうか？ > > （Thread オブジェクトとしての管理外なので，Ruby 側のリソースに > > 触れない限りは問題なしだとか，窓口 thread を一つ用意して > > それを経由するようにしなければならないとか， > > これこれに注意しないとおかしなことになるとか．．．） > > 　Ruby側リソースに触れない限りは大丈夫だと思います。たとえば、端的な例を > 言うと、管轄外ネイティブスレッドのマシンスタックはGC対象ではありません。 > 窓口Rubyスレッドをひとつ用意するのが楽なのではないかなぁ、と思います。 そううまく片付いてくれればいいのですが (^_^;， Tk 側からのコールバック処理の中でさらに Tk 側を呼び出すケースなどで やっかいなことになりそうです． Tk は特定の native thread でしか稼働しませんから (でも Tcl パートは native thread の生成もできれば 並列実行も行われる可能性がある)， 別の native thread から操作したい場合は Tk の native thread の event queue に送り込んで待ちに入り， 処理結果を送り返してもらった後に復帰などとすることになると思います． つまり，Tk の native thread の event loop の停止は厳禁です． Tk の native thread 上でコールバック処理が実行され， Ruby 側の処理を含めて一つの native thread 上で完結すればいいのですが， もしコールバック処理に別 thread が関わって「待ち」の状態が 生じてしまうと固まってしまいます． これまではバックアップとなる event loop を別 thread に作って 対処していたのですが，今回はこの手が使えないので どうしようかなぁと．．． > > その場合，ライブラリ側ではどの処理を呼べば良いのでしょうか？ > > yarvcore.h を include して YARV_CHECK_INTS() を呼ぶということに > > なるのでしょうか？ > > 　ライブラリ側で「スレッド切り替えを発生させるには」何を呼べばいいか、で > すかね。rb_thread_schedule() を呼ぶと、とりあえず切り替えてくれます。 > が、ruby コードが走るタイミングで定期的に切り替え処理が走るので、あんま > り必要はないかもしれません。ライブラリ側で長時間ブロックしてしまう際には > 必要があるかもしれません。 Tk の event loop から他の thread への切り替えのために必要です． # mode 3 では OS の native thread 切り替えに任せきるので # コントロールの必要はない (できない) という認識でいいのですよね？ 記憶違いでなければ，従来の CHECK_INTS() は 遅延処理されていた割り込み処理の実行も同時に行うものだったと思いますが， YARV では rb_thread_schedule() の呼び出しだけで十分で， 割り込み処理の方は気にしなくても良いのでしょうか？ > 　切り替えのコストは OS やシステムソフトウェアによります。つまり、ネイ > ティブスレッド処理機構のスレッド切り替えの性能によります。経験的には、従 > 来のRubyのスレッド切り替えよりも随分と高速になっています。 > > 　とくに、従来のRuby処理系はスタックのコピーが発生するため、スタックの深 > さに比例した切り替え時間が必要でしたが、YARVでは定数時間でスレッド切り替 > えを行うことが期待できます。 従来ほどには気にする必要はないけれども，Thread model 2 の場合は， 念のために調整パラメータは用意しておいた方が良いということのようですね． -- 永井 秀利 （九工大 知能情報） nagai@ai.kyutech.ac.jp