なるせにっきスマートフォン用の表示で見るなるせにっきこの広告は、90日以上更新していないブログに表示しています。ubf_selectからしか呼ばれなくて、いまはrb_mutex_lockはrbf_select使わないんだから複数のスレッドが同時に定数触るとどれか一個がrequireするけどその他はNameErrorになるらしいよ、なひさん曰く。同時に、というのがなかなか難しそうだ。require中も普通にスレッドは切り替わるということか。?reuireしたライブラリが中でThread.startしたりするしね。requireの中がスレッド切り替わるのは割としょうがないとしてなひさんが気になっているのはrequireの前のautoloadの途中でスレッドが切り替わることがあるらしいよ俺が見た分けではないが。ふむまずautoload対象テーブルから該当定数を削除して、そんでもってrequireを実行する、のだけど、requireというのはつまりファイル読み込み+evalのようなもので、ファイル読み込みはrubyのI/Oを使うのでスレッドスケジューリングが行われる。いう結論に達しました。指摘された事象は確かに発生しうる。読み込み中マークを付けておいて、それが付いてたら終わるまで待ってそのまま帰るとかいう仕様にする必要がある?わからんevalのようなもの実行中は当然スレッドが切り替わるから、ファイル読み込み部分の扱いだけ頑張ってもあまり意味ないような気がする。先にloaded_featureに登録されるのかな。requireが複数のスレッドで同時に走るとどうなるかはまた別の問題じゃねなのかな。requireが終わるまで待つのは筋が悪いねえ、終わんないかもしんないしねえそれはそうですよねえ。require終わるまで待たないと先にすすめないじゃん明示的にrequireする時は終わんないと先に進めないけどautoloadの時はようは定数だけありゃいいのでべつに待たないと進めないわけじゃないろうまあじゃあどこまでいったらOKかってのはちょっとすぐには答えは出てこないけど。self.ほげとかできるってことは、その瞬間には既にオブジェクトはある。そこでself.じゃなくて定数.にできたかなあできた、ような...できるなあ。<-この瞬間には生えてそううん、実装も、空のclassオブジェクト(moduleならそっち)を生成して、定数定義して、それから中身を実行してる。定義されないままrequireが終わったらどうなるんだろうはっはっはめんどくせえええまあ終わったならそれはそれで?とりあえず、理想の仕様はそんな感じですよね。ブロックするわけじゃないしな。今だとautoloadの中で定数定義がないとそもそもどうなるんだろう終わったところで改めてアクセスされて、普通に見つからないよエラーなひさんが言ってる現象が自分とこでも起きる感じ。できないとかなんのためそこはまた次の問題という理解。終了まで待つ以外に選択肢があるとは思えないrequire中に生成されたスレッドがその定数をアクセスした場合は?外と中を別々に処理せよ、と言われてしまうとまあそうなのかもしれない。それはautoload限らなくてrequire全般のどうあるべきかって問題かなあ。newできない定数が見えてなにがうれしいのかさっき、微妙にごまかしたんだけど、class文の実行は、クラスオブジェクトができて、定数定義されて、継承が行われて、で、それからclass文の中のブロックの実行が始まるんだけど、まあ今でも普通にその途中にスレッド切り替え起きますよね。スレッドを作ったなら定数アクセスで待ってもいいような気がするなそろそろ1.9の実装に到着した?しないしする気がしない。1.9ではその問題はパーフェクトに解決済みとか言い出す気かこのパチモンめclass文中のスレッド切り替えについて考えたらなんかrubyキモイなーと思っていろいろ考える気力を失った。1.9ではautoloadするときに定数は削除しないで、どうなるの?autoload中の場合には黙って上書きされる定義するとき他のスレッドでアクセスしたときは普通のrequireと同じでMutexで待つみんながautoloadして、ブロックしまくる、ということ?そうなるふむ。それだとautoload固有の問題はなくなって、requireの問題は残ってるけど、まあそれはそれと思えば、結構妥当だねえ1.9が1.8みたいにautoloadテーブル持ってるのかどうか知らんけど(持ってるんだよね?)いつ消すの?まあまてよ、えーといいのか。終わったときに消すのならいいが、定数を上書きするときにけすとよろしくないrequireが終わってから消せば別に誰も困らないじゃないか。終わったときにautoloadのままだったら例外きゅるきゅると戻ると、1.8はなんであのタイミングで消すんだよ!バグってたからだよ上書きするときに消すとまずいってのは?1.8の挙動はバグってことにすると、なひさんとJRubyは嬉しいらしい。上書きした後、他のスレッドが定数を参照すると、初期化が終わっていない値が取り出されるうい。定義されていないクラスオブジェクトとかなので、定義した瞬間、というのは、あまりよくないですよねー、ということですね。autoloadに限った話じゃないけど、わざわざ危険が危なくなるような仕組みにする必要はない、と。仕手から使うんだから、普通は安全ではautoloadの最中は同じ定数にアクセスしたスレッドはブロックするからしてから途中では見えないはず同じ定数というか同じファイルをautoloadする定数requireの普通の使い方とautoloadの対比ではまあそうか。requireで定義されるクラスをrequireが終わる前に別スレッドで早速アクセスしてやるぜ、なんてゆーこまったちゃんは普通に死ねよ、というのもそれはそのとおりだな。しろよばか、と表現したい結論としてはお、結論が。>requireせよ1.8のautoloadはバグってる。ありえないそれは正しい仕様があるとも言っている?<バグってる。同一ファイルへのrequireを複数スレッドで同時実行することはできず、最初に始めた子が終わるまで他のスレッドは待たされる(そしてloadedと見なされて完了する)ということでOKでしょう、という結論。なんとなく良さそうにみえるけど本当に大丈夫かな。はやめろhttp://www.atdot.net/sp/view/dgccllなにこの例外?autoloadで互いに呼び合うとdeadlockになったり8てなにautoloadでお互いに呼び合うとdeadlockになるのって当たり前じゃね?なんかみえたらいけないオブジェクトがみえてるのではないかという気になるrequireだとならなくない?ってのとautoloadって互いに呼び合う状態になってるかどうかライブラリの外に依存してる可能性が。http://www.atdot.net/sp/view/klccllそれがまさに条件(2)の話だと思う。きみたちすぐに怖いバグ見つけるね!これ要するに今言った(1)(2)の組み合わせが成立してないってことだよね。大事なところを聞き逃した気がするけど、まさにJRubyのその辺を今日直したよ。patch、revertしようよー。1.9.3nisleepしたら明示的にGVLを離すんじゃね?1.9.3に入っちゃう前に。必要があるような気がするけど確信はない。requireじゃなくてautoloadでしたか。autoloadじゃなくなるからか(1)が成立していなかったわけか。autoload_nodeから削除するのをautoload終了まで遅らせるか1.8でもload_lockってのがあってロックしてんな。1.9は正しくて、1.8の話をしてるんだよね?正しい気がする仕様を考えて、それは1.9と同じになるはずだと思ったけど、1.9の今の実装も微妙にその仕様と違ってたということが発覚したところです。https://github.com/jruby/jruby/blob/master/src/org/jruby/RubyModule.java#L28691.8なら定数削除してからautoloadに飛び込む。