From: SASADA Koichi <ko1@...>
Date: 2007-02-05T05:03:36+09:00
Subject: [ruby-dev:30256] Re: YARV の thread 	について

　ささだです．

Hidetoshi NAGAI wrote:
> model 1 はこれまでの Ruby の thread とほぼ同じと
> 考えてよいのですよね？

　はい．まだ影も形もないのではっきりはいえないんですが．

> コンパイル時に，指定された Thread model がどれであるかを
> 判定するマクロ定数は用意されますか？
> できればスクリプトからも Thread model の確認ができた方が
> 嬉しいのですが．．．

　ちょっと考えてみます．が，いちいちスレッドモデルを気にしないといけない
のは大変そうですね．なんか統一的な解決があればいいんですが．

> そううまく片付いてくれればいいのですが (^_^;，
> 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 に作って
> 対処していたのですが，今回はこの手が使えないので
> どうしようかなぁと．．．

　tcl/tk を良く知らないで言うんですが，完全に対応させるのはどちらも不幸
な気がします．

> Tk の event loop から他の thread への切り替えのために必要です．
> 
> # mode 3 では OS の native thread 切り替えに任せきるので
> # コントロールの必要はない (できない) という認識でいいのですよね？
> 
> 記憶違いでなければ，従来の CHECK_INTS() は
> 遅延処理されていた割り込み処理の実行も同時に行うものだったと思いますが，
> YARV では rb_thread_schedule() の呼び出しだけで十分で，
> 割り込み処理の方は気にしなくても良いのでしょうか？

　割り込み処理を起こすようにしてあったような．

> 従来ほどには気にする必要はないけれども，Thread model 2 の場合は，
> 念のために調整パラメータは用意しておいた方が良いということのようですね．

　なんのパラメータですか？


[ruby-dev:30253] Re: YARV の thread について
>> 　あんまり対策は考えていないんですが、そういう API を用意することは可能
>> > です。その際は、ちょっと面倒な制約が入るかもしれません。
> 
> 逆に Ruby を呼ぶことが *できない* ような native thread であるかを
> チェックするための公式な方法はありませんか？
> 必要もないのに native thread をまたぐのは無駄ですので，
> 低コストでチェック可能なら，それを利用する方が望ましいと思いまして．

　うーん．端的に言うと無理じゃないかと思います．

-- 
// SASADA Koichi at atdot dot net