日々の破片

_ Rubyでデッドロック

スクリプトがいきなりデッドロックだと言い出したのでびっくりして（スクリプトではなく）eval.cを眺めたら、なるほど確かにスクリプトのバグだった。

うんと短縮するとこんな感じ。

#!/usr/local/bin/ruby -Ks
require 'thread'
 
q = Queue.new
Thread.new do
  q.deq
end.join

実行すると次のようになる。

test>ruby dl.rb
deadlock 0xf63c8: sleep:-  - /usr/local/lib/ruby/1.8/thread.rb:281
deadlock 0x10d678: sleep:J(0xf63c8) (main) - dl.rb:5
dl.rb:5:in `join': Thread(0x10d678): deadlock (fatal)
	from dl.rb:5

追記：考えてみたら、これはスクリプトのバグを示しているのに、ソースを見なければメッセージの意味がわからんという困ったやつだな。というわけで読み方の説明。(追記の追記：スクリプトのバグじゃない可能性があるかも知れないのでwait_forの内容をまじめに出してるのかも)

deadlockという行はすべてのスレッドの状態を示す。

deadlock 0xf63c8: sleep: -  - /usr/local/……
            A       B    C  D      E

• A: スレッドの参照
• B: スレッドの状態
• C: スレッドの待ち状態理由
  • F(x): ファイルディスクリプタxで待ち
  • S: IOセレクション
  • T(x): タイムアウト待ち（xミリ秒)
  • J(x): スレッドxに対してjoin
  • P: プロセスウェイト
  • -: それ以外
• D： メインスレッドかそれ以外か
• E： ソースファイル：行番号

メインスレッドはワーカスレッドの終了を待つ。ワーカスレッドはエンキューを待つ。したがってどのスレッドも動けない。

デッドロックというのはたすき掛けの競合状態をさすと思いこんでいたので、最初、原因がわからなかった（もちろん本当のスクリプトは遙かに複雑な仕組みだ）。

RubyがOSネイティブスレッドを利用するようになっても、こういう細やかな制御はできるのだろうか？ すべての割り込みやシグナルやOSネイティブなキューによる実行状態への遷移を見誤ると無意味にデッドロックと判定されて困ることになるし、かといって永遠に待たれるのはバグを見つけるチャンスが相当減ることになる。

ちょっと考えてみたが、OSネイティブスレッドを利用した場合は、いずれにしろ、すさまじく限定された範囲でしかデッドロックは検出できないだろう（dlを利用して直接OSの機能とか呼ばれたらお手上げだ）。

プログラミング言語によるバグ検出というのは、せいぜい静的型チェックとか文法エラーに毛が生えた程度のものを想像していたのだが、現在のRubyの実行時のバグ検出能力は遙かにレベルが高いな、と思ったのだった(言語ではなくスレッドライブラリがうまくできているのだ、という言い方も出来るのでちょっと違うかな？)。

_ すげーよマイクロソフト

知らぬはおればかりなりなのだとは思うけど、良くまあ、このドメインを取得できたものだな。

Windows Live Beta。

追記：いかん。つい遊んでしまったが、相当うまくできている（マシンとネットワークが非力だからかいまいちに感じるところもある）。

#Proxy.js

_ なんとなく

エクマクマヤコンエクマクマヤコンスクリプトになーれ。