[ruby-dev:21937] Re: pthread trouble on tcltklib

永井@知能．九工大です．

From: [e-mail]
Subject: [ruby-dev:21934] Re: pthread trouble on tcltklib
Date: Mon, 17 Nov 2003 18:27:08 +0900
Message-ID: <[e-mail]>
> > ruby_init() で initialized = 1 としているところを pthread_mutex_lock
> > して，そこで ruby_thid = NATIVETHREAD_CURRENT() とするようでないと
> > いけないでしょうか．
> どうでしょう。スカラ型であることを前提にするのであれば、ヘッダ
> で何か未初期化値も用意してそれで初期化しておく、というのでもい
> いかも知れませんが。

この位置に最初に突入した native thread を ruby の native thread と
するように設定するなら，初期値の問題はなくならないですかね．
ロックしてますから，もし他の native thread が ruby_init() を
実行しようとしても，２番目以降は initialized のチェックで 
return してしまいますよね．

> > では configure オプションなしに pthread ライブラリを持つかは調べて，
> > 持ってるなら HAVE_LIBPTHREAD を定義するというのでいいですかね．
> 
> 賛成。

では，configure.in はその方向でということで．

# ．．．って，まつもとさんはそれで OK でしょうか？

順番が前後しますが，

> > ところで，RUBY_CRITICAL や TRAP_BEG/TRAP_END では pthread_mutex_lock 
> > するというのは無意味 (「たいした効果はない」を含む ) でしょうか？
> 
> ロックするのは、rubyインタプリタだけなわけですよね。例えば、そ
> こでロックに失敗した場合はどうするんでしょうか。

From: Tietew <[e-mail]>
Subject: [ruby-dev:21935] Re: pthread trouble on tcltklib
Date: Mon, 17 Nov 2003 18:48:40 +0900
Message-ID: <[e-mail]>
> 無意味です。ロックちうものはロック対象がハッキリしていてこそ意味
> があるものなので，競合するロックが無い限り無意味。Ruby をネイティ
> ブスレッド・セーフにするには根本から作り直さないと無理です。

あ，いえ，もとより完全に native thread safe にすることは考えてません．
native thread safe でない ruby 本体を native thread を用いるような
拡張ライブラリと同時に使用するという illegal な状態において，
少しでも ruby 本体が我慢して動いてくれる範囲を増せないかなと思いまして．
ruby にとっての critical section を同時実行しないようにすることで，
もしかすると少しは耐性が増すのかなとお尋ねした次第です．
もし仮にそうだとしても，問題の発現を遅らせるだけとなってしまい
「百害あって一利なし」ですかね．(^_^;
-- 
                                         永井 秀利 （九工大 知能情報）
                                             [e-mail]