観察日記 2012-03-02

%ruby

ビジーループとスレッドスイッチ

(nurse) [ruby-core:42972] ついに懸賞金が
(mame6) 50$ かあ
(nurse) tk入れないと再現しない気がするのがハードル高い
(unak) 50$だとせいぜい1時間くらいで解決しないと元が取れないな。
(unak) 再現しないんだよなあ。
(nurse) 環境整えても?
(unak) どれくらい真面目に整えるかによるが、とりあえず手元環境でこのコードでは。
(nurse) tkすらいれずに./miniruby -e'Thread.new { loop { a = 1 } };Thread.pass; loop{p 2}'だと無理だったレベルしか試してない
(unak) 劇重なので嫌なテストコードではある。(無限ループなので)
(nurse) loopあるからタイマスレッドの割り込みきくはずだよなぁ
(nurse) loopあるからjumpあるから
(unak) ただまあ、劇重なので固まってるように見える可能性は否定しない。
(nurse) なるほど
(mame6) ubuntu で試したら問題なく動いた
(unak) 100msecだったっけ。
(nurse) 250
(nurse) 1.9.3では
(unak) あり?
(unak) #define TIME_QUANTUM_USEC (100 * 1000)
(unak) に見える。
(nurse) あり
(unak) まあ、別に100でも250でも大差はないんだが。
(nurse) unsigned long limits_us = 250 * 1000;こっちじゃない
(unak) おや
(unak) というのはともかく、sleep 0を入れればちょースムーズに動くので、なんだかなー、と思わなくもない。
(nurse) sleep 0でいけるって事はnative threadな気もする
(mame6) hang っていうからには少なくとも数秒は動かないくらいの状態になるんだよね
(mame6) ビデオを見ればいいのか
(mame6) 6 回再生に泣いた
(mame6) なんと、重いだけのように見える
(unak) うむ
(mame6) resize できてるよ。遅いけど
(mame6) そういうのは hang とはいわない
(unak) そりゃ重かろう
(unak) としか言いようがない。
(nurse) なんでそんな重くなるの?
(nurse) あ、コアの数?
(mame6) 関係あるのかなあ
(nurse) リサイズってnative threadで動いてない?OS側の
(nurse) コアが2つあれば無限ループと同時に動く
(unak) よーわからんけど、250msに一度しか処理しないならあんなもんじゃね?
(nurse) あぁ、そっちか
(unak) ぴちょんだと100バイトコードごとにスレッド切り替わると思うので
(unak) rubyよかスムーズじゃないかなあ、とは思う。
(unak) 再コンパイルとか嫌過ぎるので試す気起きないが、250msを10msとかにしたら相当スムーズになるのではないかと思う。
(tal_) native threadで動いててもcallbackでRubyコードのブロックが設定されてないかどうかの チェックが入ってたりするのではないだろうか
(tal_) そのチェックの為にGVLを取りにいかざる得なくてthreadの切り替わりを待つ事にみたいな
(mame6) Ubuntu ではそんな言うほどラグが起きないのだけどなんでだろう
(nurse) そして今更動画を見た、なるほど、これをhangと言われてもわかるわけ無い
(nurse) 1.9.3/trunkでも?
(unak) ふうむ
(unak) 10msに変えてもそんなに軽くならなかった。
(tal_) 動画みてhangって何の事をいってるのか分からなくて本文を読んでしまった
(mame6) 1.9.3p0
(mame6) ハングって嘘ついたので損してるなあ
(tal_) パフォーマンスバグかな
(nurse) バグというか仕様というか
(unak) もうちょっと真面目に考えるか。
(tal_) tkのコードを読む必要があるのが
(tal_) 重い。
(nurse) しかし、$50だと飲み代にもならんな
(nurse) 1ドル1000円くらいにならないと
(mame6) 下手に金を出されると損得勘定を始めてしまうのだな
(nurse) 何事もやるなら徹底的にというわけで
(nurse) シグナルの割り込みは100msでチェックするとかかな
(nurse) いや、シグナル割り込みは100msごとに見てるか
(unak) んー
(unak) なんか難しいコードだなあ
(unak) ふむ。
(unak) limits_us と TIME_QUANTUM_USEC の両方を小さくしないと意味なかった。
(unak) というわけで、例えば両方10msにすると、かなり滑らかになる。
(nurse) シグナルは回収するけど、きててもRubyスレッドスイッチしない?
(unak) 250msに一度しかスイッチしないってことじゃないのん
(unak) つかまあそういうコードだと思うんだけど違うのかな。
(unak) そうさなあ。わかりやすいのは
(unak) Thread.new{loop{}}; loop{p Time.now.usec; sleep 0}
(unak) こんな感じのコードですか。
(nurse) なんかバグっぽい気がするな
(unak) つか、これで250msごとにしかスイッチしないってのを意図して今のコードがあるとしか思えないのだが。
(unak) 確かこさきさん主導だったと思って、軽く疑義を提示したような記憶もあるのだが...
(nurse) そんなことあったっけ
(nurse) あったとしても私はきっと読まないだろうが
(unak) 検索しにくい
(nurse) 変更から追った方が早そうだ
(nurse) r32064
(unak) しかし何の説明もなくて泣ける。
(nurse) うちのgitは下に近永さんの解説が出てくる
(unak) それによると?
(nurse) fairnessを捨てて走り続けるようにしたとある
(unak) いやまあもうたどり着いたが
(nurse) そういえばそんな話を聞いた覚えはある
(unak) r32302は本質的にはコードの整理だけだな。
(unak) 1.8だと10msなんだっけか
(nurse) 1.9.2でもそんなじゃないっけ
(unak) まあ、忘れちゃった
(nurse) シグナルが来たら即処理して欲しいかもしれない
(unak) まあ、とりあえず、1.9.2では快適そのものではあるな＜件のコード
(nurse) [ruby-dev:43465] これか
(nurse) [ruby-dev:43471] さすがわたし
(nurse) そういえばsleep 0よりThread.passの方が正しいな
(unak) そうですな
(unak) でもsleep 0の方が短くて書きやすいんだよもん
(unak) これはUnix脳っぽい
(nurse) うらぎりものめ
(unak) で、matzは「直すべき」つってんだから直すべきだよね。
(unak) そろそろ$50が見えてきた。
(nurse) こさきさんは直すべき。
(unak) 小崎さんは本当に250msに一度しかスレッドスイッチしないことを企図してたのかなあ。
(unak) うちの環境だと400msくらいになっちゃうんだけどｗ
(nurse) おらガチャピン早く出てこいガンガン
(nurse) そっちがおかしくね?
(unak) というのは、100msに一度しかチェックが行われないので、
(unak) 250msというのは実質的には300msになる。
(nurse) うん
(unak) で、250ms経ったかなー、というチェックに仮に50ms以上かかるならば
(unak) 次の100msまでさらに遅れるので400msになる
(unak) のではないかなあ。
(unak) 50msはかかりすぎな気もするが。
(nurse) 他のスレッドが100ms動いてるのかな
(unak) あ、自スレッドが100msか
(unak) さっきのだと、sleep 0なわけだけど
(nurse) 自分が誰かによるが
(unak) 即時にpassする気もするんだがなあ。
(nurse) いや、もう一人いるでしょ
(nurse) tkのGUI側スレ
(nurse) いや、そっちはいないのか?
(nurse) tkのmainloopスレがいるよね
(unak) いや、Thread.new{loop{}}; loop{p Time.now.usec; sleep 0} の方
(unak) 誰でも再現できる優しいコード。
(nurse) そっちの話か
(unak) Thread.passだと300msになった
(nurse) どう見るんだ
(unak) sleep 0だと100ms寝るのかな。
(nurse) 4くらいかな
(nurse) sleepは0を与えても寝るはず
(nurse) いや、仕様外だっけ?
(unak) というわけで、納得した。
(unak) まあ、100ms寝ても許せる気はする。
(unak) 微細なバグのような気もするけど(thread_win32.cあたりの)
(unak) ま、そんなこんなだけど、現象はこれで納得だよね。
(nurse) うむ
(nurse) 英語で頑張れ
(unak) ruby18だと劇速で感動する
(nurse) わたしは久しぶりに観察日記に日本語で載せよう
(unak) 俺は小崎さんを叩こう。

unak: そもそも彼の言ってる問題再現できます？
うん。
しかしtk何ぞ入れなくても ruby -e 'Thread.new{loop{}}; loop{p Time.now.usec; Thread.pass}' でいいと思うよ。
はて。Windowsだと sched_yield ないからタイマースレッドの起床間隔が10ms から100msに変わったのだけが効きそうな気がする。これはささださんに言われて１００にしたはず
Windowsかんけーないと思うけどねえ。
俺のテストコードだとNetBSDでも300msごとなので。
で、まあ、一番知りたいのは、こうなることを覚悟の上でこの変更をしたのかどうか、だな。
うん
まっとうなコードが得をして、アホなコードが損をするなら割りにあうよね。という話になった記憶がある
{unak} > 「直すべき」でしょう。
だから、そうなってないように見える。

結論は例えば「既に合意済み。コードによっては250ms(300msだけど)に一度しかスイッチしないがそれはてめーのコードが悪い」でもいいんだけど、
その場合は「既に合意済み」の部分がどこにあるのかを知りたい。
なお、今のところ、matzの「直すべき」しか見つけられていないので、ダメ出し食らってるようにしか見えない。
ささださんのコメントの 10ms is too small for user level thread scheduling on recent linux (tested on 2.6.35) の意図というか根拠がよくわからないなあ
ハングはしてないから別件という認識
何と何が
ビジーループ書いて遅くなるのは別に不思議じゃないという感触かなあ。
ハングしたらだめってのと、１．９．２より遅いんじゃねって指摘
$50の人の「ハング」は、遅いという意味です。
動画見ろ
詳しくはビデオを参照。
動画みた。あれ遅いだけだよね。それにそんなに遅くないよね
俺も動画撮ろうか。どうやって撮るかわからんけど。
1.9.2と比べたら笑えるほど違う。
ハングっぽくおそいってのは、1.9.3だと1分かからないテストが1.9.2だと8時間越えとかそういうレベルに対しての指摘だったと思う
むしろ「ハングっぽくおそい」が何の話かよくわからない。
"the GUI will hang out badly, try to resize window to see it yourself"
あの時期にそういう話が何件かきていたはずなのです
あの時期とは?
matzが直すべきといっていた過去ログぐらいの時期
だめだな。記憶力が十分じゃないからささださんがいるな
Threadに機能を足そう。busyloop回したいけど他への影響を抑えたいthread向けに。
シグナルが来たらもっと早くスイッチするとかだとダメなんだろうか
それはすでにやってる気がする
あのmatzの「直すべき」の頃は、そもそも問題のコードがcommitされていない。
commitされる前の時点で、こさきさんが
ちゃうちゃう。1.9.2も劇遅になるケースがあるのです
むーん
で、ｔｋ対策で考えるといまthread.c で２５０ｍｓになってる強制スイッチタイムアウトを100msにするのが一番てっとりばやいかなあ。１００だと遅さが体感できない
とてとて体感できたのですが...
たぶんWindows system内部でいろいろごにょごにょバッファリングしてるからあんまり早くしても意味ないと思うし
ん、どういうふうにコードいじりました？
[ruby-core:42974]
{unak} http://mla.n-z.jp/?ruby-core=42974
1.9.2だとストレスレスなのはなんでだろーなー
と思ったけれどめんどくさくて細かく見てない。
... ちょっと言葉足らずだった。
$50の人が [ruby-core:42981] で言っているように、こういう姑息な変更をしてもWindowsではそれなりにしか変化がない。
{unak} http://mla.n-z.jp/?ruby-core=42981
一方で1.9.2は大変滑らかに動く。
不思議だなあ。
わたしにWindows環境をまた構築せよと言われてる気がする
いや、別にそこまでは。
そうか、たぶんsleep 0で100ms寝てんじゃね? ってのと同じ話かなこれは。
他のスレッドがなければ寝ないあたりがたち悪いな
ストレスレスというのはｔｋが？
tkが。
動画を撮りたいところだな。
そちにはbotはいないんじゃないｄすかね。
こっちを抜ければ too many connections が消えるのだろうか。ちょっと抜けます
paste>
{ko1_ndk} http://www.atdot.net/sp/view/8tw20m_kosaki3
usaさん、このパッチあててｔｋ動かしてもらってよい？
Ｍａｃだとこれでもぬるぬる動く
ほいさ
} else { かこわるい
しばらくおまちください...
Ｒｕｂｙだと改行するんだっけ？
うん
結論としては変わらず。
いや、ちょっと反応よくなってるのかなあ。気持ち程度だけど。
Windowsは謎だなあ
gvl_yield()とelseの中身って同じじゃね?
ああ、Windowsではそうだった
ぶ
なんでこんなに違うコードなんだ?
WindowsのスケジューラにLinuxとかと同じ問題があるかどうかわからんかったからWindowsだけ1.9.2からあんまり変えない方針が継続してる
えー
結局の所、CPUとOSのスケジューラとRubyのスケジューラが、それぞれ違う事を仮定してるというのが本質だったので
かわりまくっとるやんけー
ははは
まあバグ報告あるたびにコードいじりまくったですけー
Windowsだけ1.9.2レベルまで戻す... のもなんだかアレですね。
1.9.2では結局どうしてたんだ
まず原因追及かなあ。と
ruby -vが無いとvalidationで怒られてた
関数名が変わっていて比較が困難
ああ、わかった。ここか。
タイマ割り込みごとにgvl_yield()してたと思ってほぼ間違いないな。
で、タイマ割り込みが10msごとだった、ので
結論としては10msごとに処理してるだけのはずなんだけどなあ。
unakパッチと僕がさっき貼ったパッチ両方あてたら1.9.2と同じになります？
ちょーっと重い気がするけど、許せる範囲
1.9.2と差分あります？
動きに?
うん
両方知ってたら明らかに差があるとわかるね。
なぜだろう...
じゃあ、なにか僕の知らない変更があるなあ
ちゃんと調べた方がいいフラグが立っているのは分かるんだが
Windows環境構築ってすんげえめんどくさい
うまく説明できないのだが、1.9.2はぬるぬる完璧
1.9.3はぬるぬるしないがストレスを感じるほどではない
ちがった。1.9.3改は、だ。
(1.9.3改と言いつつtrunkだから2.0.0だが)
あれ、じゃあストレスを感じるのはどれです？
素の1.9.3およびtrunk
ああ、1.9.3改==trunk ではなく 1.9.3改 ≒ trunk改といっていたのか
1.9.2>(ぬるぬるの壁)>unakパッチ＋小崎パッチなtrunkまたは1.9.3>>>>(ストレスの壁)>>>>unakパッチなtrunkまたは1.9.3>>>>>>(操作不能の壁)>>>>>>素のtrunkまたは1.9.3
こんな感じ。
「ぬるぬるの壁」ってなんかきもい
あーとんさんの環境構築本どこいったー
g>達人出版会 arton
{znz_v} google web bot: 刊行記念：artonさんインタビュー 第1回 - 達人出版会 - http://tatsu-zine.com/books/1/pages/interview1 (and 351 hits)
あー
わかたかも
なんと
1.9.2ではcritical sectionでロックしてたのが、1.9.3以降はmutexになってる。
ので重い
ああ、そういえばささださんが変えてましたね
これはしゃーないのかなー。
critical sectionにしてpthreadと同じく、数百ミリに一回強制スイッチさせるのがいいんじゃないかと
動作が同じになって考えることが減るという意味で
ただ２５０ｍｓは１００ｍｓまで下げないとだめだな
100msじゃだめなんじゃね、というのが俺の結論なんですけどね。
あ、でも確証がほしいので、いちどcritical sectionにもどしてビルドしてみてもらえません。ifdefでのこってるはず
のこってねー
Macではぬるぬる動くのになあ
そうだっけ
じゃあ、gitさんにがむばってもらって
visual studio expressのダウンロードが遅すぎて今日は作業継続不可能やな
MSめえええ
あめりかしょぼいな
ネットワークに関しては日本と韓国が世界一じゃないかな
韓国はADSLだから、とdisる
なので日本が世界最強
日本にはYBBとNTTがいたのでよかった
gitさんは使わないので、えーと
というか、そういう感じの違いじゃないよなこれ。
むしろYBBの手柄だよな。NTTが自発的に頑張る可能性があったとはおもえん
ほう
でもYBBだけだったらきっと今もADSLなんで
なるほろり
NTTだけだったらきっと、さすがに今もISDNってことはないだろうが、光だけど10Mbpsとかな気がする
ありうる
うーん
10ms化＋小崎パッチ＋critical section化で
ぬる、くらいにはなった。
が、1.9.2ほどぬるぬるしてない
うがあ
まず100msへの変更はベンチはかり直して、もんだいなさそうなら入れてしまおう。これだけでMacは解決する
あと何が違うんだろうなあ。
正直おもいつかないです
じつはｔｋが違うってオチはないですよね？
ははは
tkはともかくtcltklib.soは違うかもなあ
しかし同じのを試すのは(バイナリ互換性がないので)難しい。
誰だよ2.0.0に上げたやつは
下げればいいじゃない
どんだけ俺を苦しめる気だ
差分を見る限り、そんな大きな差がある感じではないな。
$50遠いなあ。
まあ WindowsはWindowsに興味ある人が直してくれそうな気がするからほっとくかな
興味ある俺が一括revert
Windows以外に影響ないならそれでもいいですよ
あると思うけどWindows以外に興味がある人が直してくれそうな気がするからほっとく。
いやいやいや
違うこと言ってないのにぃ
ところで、真面目に聞くのですが、今はタイマ割り込みが100msで、タスクスイッチ(という言い方でいい?)が250msじゃないすか。
あれ、へんだよね
このそれぞれの数字ってなんか根拠あるのん?
100はささださんの実測値、250は僕の実測値
で、こさきさんは後者を100にしようとしてるんだよね?
そうです
これさあ、後者をもっと小さい値にするのはどうなん?
前者より小さい場合の意味があんまりないんじゃないかなあ
Rubyでスレッドの優先度使ってる人ってほぼいないと思うし
Windowsで前者を小さい値にしようとしてるのだ。
Windowsだけ前者を10msに戻すというのはありかもしれないですね。そういえば
priorityでビットシフトするので、前者100の半分の50くらいまでなら小さくしてもいいんじゃないか。
或いは単純にデフォルト値はTIME_QUANTUM_USECでいいのかもしれない。
それか。
うん、それかな
とりあえずそうしてみましょっか。
シグナルとかで割り込んだときはスイッチする義務はない。という分かりやすい意図になる気がします
とりあえず、今回はそこで妥協しよう。
意図的に放置してたるいさんを釣るつもりだったのに
usaさんに本気だされてしまって崩壊した
talさん昨夜ちょっと見てたけどね。
busy loop＋Thread.passは手元の環境では50msくらいになるので1.9.2と同じ。
というか1.9.2だと安定しないな。
10msくらいのこともあれば130msくらいのこともあるな。
なんでやねん :)
たぶんWindowsスケジューラには僕のしらない謎がある
それは不思議でもなんでもなくて、pthread版でも1.9.2はそうです
へー
まあ、50msで安定するならそれはそれでよいや。
cmpxchg一発でロック取る最速ロックだと２つのスレッドのどっちが勝つかは運次第だから
これが20msくらいだとぬるぬるになるってことなのかにゃあ。
ワーストケースはすごく悪くなる
20msは要求されてないと思うけどなあ
俺もそう思うんだけどねえ。
スレッドをあまり頻繁にスイッチさせるとスループットに悪影響があるし
CriticalSectionにすると... ばらつきがあるな。
CriticalSectionとはそういうAPIだとおもってた
個人的にはmutexが揃いすぎていて気持ち悪かった。
CriticalSectionにするとそういう意味では1.9.2と同じ感じ。
で、ぬるぬるしないので、んー
これでスイッチの頻度は同じくらいになってるってことなんだけどなあ。
わかんねー
明らかに$50で割に合わない
うわ
意味ないはずと思いながら1msにしたらぬるぬるすぎワラタ
WindowsってWindow処理おそいの？
と疑問におもった
そういうことじゃないと思うが。
なんでこんなにリニアに動作に影響するんだ?
むしろそれがキモイ
まじで1msにしとくか。
どれくらい悪影響があるんだろうか。
うーん
make benchで実際にはかったらいいと思うの
windowsのスケジューラがまだラウンドロビンベースなら実はそんなに悪くないアイデアかも知れない
べんちまーくちう
ああ、いや、やっぱり1msに一回コンテキストスイッチはやり過ぎな予感
まあ、ベンチの結果を待ちましょう。
つかむっちゃ時間かかるんだよなあ。
しかし、ぼーっと経過を眺めている感じだと、誤差程度しか違いがないものばかり。
影響がありそうなのは後ろのほうかな。
終わった。
有意な差があるのはio_file_createとvm_thread_mutex3の2個だけ。
前者はなんでじゃろ?
後者は2.3秒→30.9秒なのでさすがにまずい気がする。
本当はtcltklibのeventloopはGVLを解放した状態で回って、なんかイベントがあってrubyコードを実行しないといけなくなった時だけ改めてGVLを確保しないといけないのではないか。
という結論に達したけどまあいいや。

ruby-jaで名前を呼ばれてたがログが長いのでとりあえず放置していいという事だけ認識して満足した
要約すると、$50問題特命担当に就任です。
kosakiさんがあきらめて就任した まで読んだ
要約するとtalさんまかせた
unakさんはWindowsのダークサイドに落ちていってそれっきりです。
なんという押し付けあい。
{unak} unsigned long limits_us = TIME_QUANTUM_USEC;
後のダチョウ倶楽部である。
は、小崎さんが入れてくれるってことでOK?
りょうかいしました
Ruby2.0ではThread毎にrenice(limitを短縮)できるように提案してみよう
Windowsで何にするか(1msはさすがに酷いよな)は適当に考えて私が入れておきますです。
いっそ0でいいんだったりして。
write(2)をブロックさせる手っ取り早い方法は何か。
pipeかなあ
tcltk.cのコードむつかしいな
tcltklib.c だった
ブロック状態のioにsyswriteして待たせておいて、ちょっと仕掛けを施してからブロックを解除すると... あらふしぎ! SEGV! っていうのができる気がするのである。
さっきruby-devに投げたreadの逆だけど、readだと[BUG]だがwriteならきっとSEGVにできる。
むつかしいな。これなにがおきてるんだろう
tcltklib見てる?
いちおう
lib_eventloop_coreの中でぐるぐる回っている。
なんとなく、UIスレッドをふつうのnormal priorityスレッドとして扱う必然も無い気がしている
なんかイベントがあったら拾って処理。
あと、tcltklib.cで１．９系だとタイマーが５ｍｓで貼ってるのだけど意味が分からん。どのバージョンでもそれは反応できなくないかなあ
確か800回転に1度くらいrb_thread_schedule()
とかいう感じだったと思った。
今回の例だとずっとrb_sleep_forever()で寝ていて
resizeのときだけ起きてきてると思うんだ
へ
あれ、ちがう
元報告者のコードでいえば
{unak} Thread.new { loop { a = 1 } }
と
{unak} TkRoot.new.mainloop()
が絶賛競合中。
mainloop()のなかでsleep_foreverしてない？
しない
lib_eventloop_core()みてたんだけど
では、どうやって寝てるんですか
寝てないよ。
loop { a = 1 } は先ほどから見ていたタイミングでしかGVL離さないので普段はそっちが元気に空回り。
250msというか300msに一度mainloop側のスレッドに処理がうつるけど、割とあっさりrb_thread_schedule()にたどり着いてすぐ制御をloop { a = 1 } に奪われちゃう。
なので、300msごとにしかイベントを拾えない。ゆえにかくかくしちゃう
というのが現象の全体です。
tcltklib.c ってそういうビジーループ的な流れをするのが仕様なんですか
テキトーなタイミングでrb_thread_schedule()呼んでるのでそこまで悪質ではない。
簡略化すると loop { 800.times{ do_event()}; Thread.pass } と書いてるようなものなので、
ガチャピンも大満足、のはず :)
この何もしてないタイマーハンドラーはなんのためにあるんだろうなあ
謎ばかりだ
タイマーハンドラ使うの、自分以外にスレッドが存在しないときだけじゃないすか?
{unak} if (thread_alone_check_flag && rb_thread_alone()) {
のパスでしか使っていないはず。
いや使うのかなあ。まあたぶん使わないと思っていいです。無視無視
とりあえず、小崎さんには、問題のスクリプトを ruby -d で実行してみることをお勧めする。
(スクリプト冒頭に #!ruby -d でも可)
DUMP*ってのがだらだらとstderrに表示されるのでどこ通ってるかはわかる。
-d ってなんだっけ
--debug
ああ、嘘ついた。
800.timesじゃなくて(800/10).times相当だ
Macだとresizeはtkにcallbackされてないという知見が得られた。ほんとうだろうか
mjsk
であればそりゃWindowsみたいにひっかからないよね。
まあ普通はmain windowだけということはありえないので、resizeするときに子windowの調整のために通知は飛ぶはずだと思うけど
（ぜんぶ推測です）
まあスケジューラ的にはビジーループしてるやつと、ビジーループしつつThread.passしてるやつらはどれだけぞんざい扱ってもいいやつらなので急速に興味がうせつつある
あきらかにスレッドスケジューラでやるのは筋が違うだろう的な
でも、ぼくちんもっともっと頻繁にタスクスイッチされたい！
その辺、GCのパラメータが調整できるようなったように調整できるといいかもしれないですね。
しかし、ここで疑問なんですけど、
僕に聞いてます？
真面目にGVL解放してイベント待ちしたとしても、
イベントが起きてrubyコードで書かれたハンドラに突入するためにGVL取りに行ったら
やっぱり最悪300ms待たされるよね。
うん。さっき考えてたのはUIスレッドが奪いに来たら優先的にGVLわたしてあげる仕組み作った方がいいんかなーというネタだった
難しいことが起きてない限りGVL分捕るAPI
は確かにあるといかもしれんすね。
(そして悪用される)
スレッド間の優先度だと悪用されてもたかがしれてないですかね
あほなライブラリ書かれたらだめだからやっぱりだめなのかなあ
まあ、APIなら拡張ライブラリなので、
カジュアルユーザーがrubyでビジーループ書くよりはアホなことされる可能性は低いでしょう。
ところで
知ってたら教えてほしいのですが、1.8のスレッド切り替えのタイミングっていつでしょ？
何msだったかな。
なんであんなにビジーループ耐性高いんですか
タイマーなんだ。意外っ
タイマーというか
まあ時々時計見て「あ、そろそろ時間だからスイッチしなくちゃ」みたいな
うーむ
総合すると、やっぱりtkが特殊すぎるのでworkaroundとしてはタイマースレッドの感覚を切り替えるAPI用意してｔｋ使われたら頻繁に起こすのかなあ。消費電力無視して
とても気に入らない
0.06秒ですた。
＜1.8
合ってるかな。
てことは60ms? 1.9.2よりも長いのか
そうはみえんが
気が向いたらもっと早く切り替えるかもしれない。
どう見ても1ms以内に切り替えてるような。
0.06msなのかまさか。
それはないよなあ。ははは
1msだった。
ああ、そうだったそうだった。setitimerがあればタイマーか。
なければまあおよそ500ノードほど処理したら、かな。
1msとはまた無茶なことを
ああ、OSの制限で１ｍｓ出来ないのを見越してASAPという意図なのだろうか
俺が桁を見間違えてなければ。
... 見間違えてるかなｗ
10msだ。
というか、1.9の初期が10msなのは当然それを引き継いでるわけだな。
なるほど
よく考えたら
pythonも3.xはタイマー貼っててRubyっぽく数百ｍｓって聞いたから同じ事がおこるんじゃないだろうか
ほほう
100バイトコードってのは2.xかしら
たしか
まあ、ruby 1.8もタイマー使わないプラットフォームなら500ノード(くらい)なので
お互いナカーマなわけだな。