今日はスレッド切り替え、VM のロックの実装のアルゴリズムの改善という大きな修正が入ってます。
naruse:r29953 2010-11-28 04:22:53 +0900
Net::HTTP のドキュメント(コメント)の添削です。[ruby-core:33433]
svn:r29954 2010-11-28 04:22:54 +0900
version.h の日付更新。
luislavena:r29955 2010-11-28 04:49:58 +0900
Windows で標準出力、標準エラー出力への描き出しは WriteConsoleW を利用するようにされています。[ruby-core:33166]
文字エンコーディングの自動変換でおかしな出力になることがあったみたいです。
[追記]Windows のコマンドプロンプトのバグのせいできちんと出力されないのを回避しているとのこと[/追記]
ko1:r29956 2010-11-28 05:15:59 +0900
いくつかの修正が入っているようです。まず VM の GVL(Giant VM Lock でしたっけ)の取得のAPIをリファクタリングしています。また pthread 版のロック取得のアルゴリズムを新しいものに変更しています。元のものも条件コンパイル(GVL_SIMPLE_LOCK)で残されています。新しいアルゴリズムでは GVL の取得待ちキューが用意されていて、待っている順番にロックを取得するようにされています。このため GVL には pthread_cond_t も含まれるようになっています。これで GVL 取得でスレッドがスピンロック状態(ひとつのスレッドが繰り返し GVL を取得してはすぐ解放解放してはすぐ再取得というのを繰り返すことがありました)になるのを防いでいます。Windows 版はよく読んでないですが Mutex のロックだけのようです。[ruby-core:26694] [ruby-dev:42315]
nobu:r29957 2010-11-28 14:46:32 +0900
fork した時にデッドロックしてしまっていたので pthread_atfork は親プロセスだけで設定して fork した子プロセスでは再設定しないようにしています。ということは 2段 fork したらまずいんですよね、きっと。2段 fork は daemonize の時の常套手段ですが、 1.9 には Process.daemon があるからまあ使わないか。
[追記]コメントで教えていただきました。 pthread_atfork の設定は fork した時子プロセスに引き継がれるため、再度 pthread_atfork を呼ぶ必要はないようです。むしろ呼ぶと固まるようですね[/追記]
nobu:r29958 2010-11-28 14:48:31 +0900
r29956 の変更の警告除去や関数プロトタイプの追加など少し添削されています。
nobu:r29959 2010-11-28 14:55:49 +0900
もうひとつ thread_win32.c でもフォーマット指示文字の変更や不使用変数の削除などの小さな修正。
nobu:r29960 2010-11-28 14:56:39 +0900
struct argf のメンバを少し変更しています。
