[ruby-dev:45343] Re: 非同期割り込みに対する対処案（日本語版）

議論には参加していませんが、概要まで訳してみました。

How can asynchronous interrupt survive

Terms
trap handler: a block that should be executed when a signal registered to trap
	the content (...) of trap(SIGINT){...}

asynchronous interrupt: unintended event such as Thread#raise or trap handler

意図しないってなんか変じゃありません？

Interrupt check: Determine if there is any asynchronous exception (未定義),
	and raise an error or invoke trap handler if there is any exception.

Blocking procedure: a procedure that may be blocked including I/O

Summary
	Ruby will provide a primitive to regulate the timing to check
for the asynchronous interrupt. Three kinds of regulation should be
provided
	0. check as frequently as possible (this is the current behaviour)
	1. check at a blocking procedure.
	2. don't check
Note that the behaviour can be specified per exception class.
Therefore, SignalException and its descendants are checked frequently.
This enables to write a code that Ctrl-C cause interrupt but 
exceptions like TimeoutError are delayed to a safe point.


On 2012/03/11, at 20:35, SASADA Koichi wrote:

> 　ささだです．
> 
> 　開発会議で出た「非同期割り込みがこの先生き残るには」という議論を，とり
> あえず日本語でまとめました．まだあまりまとまっていない（すみません）の
> で，すみませんが日本語で出させて下さい＆突っ込んで下さい．
> 
> 　あとで英語化したいと思います（してくれると嬉しい）．英語化できたら，今
> 後はそっちということで．
> 
> 
> 
> 用語：
> ・trap ハンドラ：trapで登録するシグナルが来たときに行うブロック
> 　　trap(SIGINT){ ... } の ... 部分
> 
> ・非同期割り込み：Thread#raise や trap ハンドラなど，意図しない
> 　　イベントを，ここでは非同期割り込みと呼ぶ
> 　（他にもあったら教えて下さい）
> 
> ・割り込みチェック：非同期例外があるかどうかチェックし，もしあれば
> 　　例外を発生刺せたり trap ハンドラを実行したりする
> 
> ・ブロッキング処理：I/O などで，ブロックするかもしれない処理．
> 
> 
> 概要：
> 　非同期割り込みをチェックするタイミングを制御する primitive を提供す
> る．制御の種類は次の通り，
> 　　0. なるべく頻繁にチェックする（これまで通りの動作）
> 　　1. ブロッキング処理のタイミングだけチェックする
>    2. チェックしない
> 　ただし．チェックする例外クラス（の祖先）は指定できる．
> 　なので，SignalException （を継承した Interrupt）は頻繁にチェックする，
> すなわち Ctrl+C はだいたい効く，しかし，TimeoutError のような例外は安全
> なところまで遅延して処理するといった挙動が容易に記述できる．
> 
> 
> 背景：
> 　Thread#raise を使うと，スレッドに対していろんなちょっかいを出すことが
> できる．また，trap(signal){...} とすると，任意のシグナルについて対応する
> ことができる．
> 
>  # 例1
>  th = Thread.new{
>    begin
>      ...
>    rescue NantokaError
>      ...
>    end
>  }
>  th.raise(NantokaError) #=> th に NantokaError を強制的に引き起こす
> 
> 
>  # 例2
>  q = Queue.new
>  th1 = Thread.new{
>    q << calc_in_algorithm1
>  }
>  th2 = Thread.new{
>    q << calc_in_algorithm2
>  }
>  result = q.pop
>  th1.raise(TerminateCalcError)
>  th2.raise(TerminateCalcError)
>  # アルゴリズム1，2 で計算して，どちらか先に答えが出たら，
>  # もう1つのほうを止める
> 
> 
>  # 例3
>  trap(SIGINT){
>    # 何か後処理
>  }
>  trap(SIGHUP){
>    # 何か reload 処理
>  }
>  server_exec # サーバの処理
> 
> 　なお，現在の割り込みチェックは，RUBY_VM_CHECK_INTS() で行っており，メ
> ソッドの起動時，リターン時，前方へのジャンプ時，ブロッキング処理の前後で
> 行っている．
> 
> 
> 問題点：
> 
> 　Thread#raise だとかが上がってくるタイミングは制御できないので，例えば
> ensure 中で後処理をしていた場合に困る．
> 
> 　例えば，例4 は timeout の実装（の簡略版）ですが，yield で起動したブ
> ロック中で，ensure を用いて何か資源の後始末をしていたとしても，その後始
> 末中に（ensure 節実行中に）TimeoutError が発生してしまう可能性がある．
> 
>  # 例4
>  def timeout(sec)
>    timer_thread = Thread.new(Thread.current){|parent|
>      sleep(sec)
>      parent.raise(TimeoutError)
>    }
>    begin
>      yield
>    ensure
>      timer_thread.stop # close thread
>    end
>  end
> 
>  timeout(3){
>    begin
>      f = open(...)  # open(...){|f| ...} でいいんだけど，まぁ例として
>    ensure
>      f.close
>    end
>  }
> 
>  では，ensure だけでいいのか，というと，それ以外にも問題がある．例えば
> 次に示す例5について考える．
> 
>  # 例5
>  begin
>    f = open(...)
>  ensure
>    f.close if f
>  end
> 
> 　open(...) で開いたものを，"f =" でローカル変数に代入が完了する前に割り
> 込まれたとき，f は nil のままなので ensure で close されない．この例の
> File の場合は GC で閉じることも可能だが，解放を必須とする資源一般を考え
> ると問題である．
> 
> 　この点について，例えば，行末まで割り込みを許さない（行末だけチェックす
> る），といった解決案も提案されたが，"f =" や "open(...)" がもっと複雑
> だった場合，その解決では無理である（例えば，"foo.bar =" は複数行のメソッ
> ドの場合がある）．
> 
> 
> 提案：
> 　非同期割り込みをチェックするタイミングを制御するための仕組みを新設す
> る．原案は [1] にあるとおり．ただ，名前については今後検討する．
> 
> 　制御の種類は次の通り，
> 　　0. なるべく頻繁にチェックする（これまで通りの動作）
> 　　1. ブロック I/O のタイミングだけチェックする
>    2. チェックしない
> 
> 　0 はこれまで通り．
> 
> 　1 は，POSIX thread の cancellation point らしい．長時間ブロックする処
> 理は Thread#raise やシグナルでキャンセルすることが可能．
> 
> 　2 は，一切チェックしない．完全に非同期割り込みセーフに処理することが可能．
> 
> 　ただし．チェックする例外クラス（の祖先）は指定できるようにする．これに
> より，例えば SignalException （を継承した Interrupt）は頻繁にチェックす
> る，すなわち Ctrl+C はだいたい効く，しかし，TimeoutError のような例外は
> 安全なところまで遅延して処理するといった挙動が容易に記述できる．
> 
> 
> 議論：
> 
> ・デフォルトをどのモード（前節 0～2 のこと）にするか？
> 　・モード 1 で困る人はどれくらいいるか？
> 　（いないならデフォルトこれでいいんでは？）
> 　・計算スレッドは止めても困らないので，例2のような場合はこれまで
> 　　通り止めたい，という，モード 0 を期待する例はある．
> ・ensure 実行時に自動的にモードを変更するか？
> 
> ※ええと，すみません，いろんな議論があったと思いましたが，誰か補完して下
> さい...．
> 
> 
> 余談（というか TODO）：
> 　rb_blocking_region() 時に強制的に終了時に CHECK_INTS() しているのはけ
> しからんので，CHECK_INTS() を呼び出し側でさせるバージョンを作るべきである．
> 
> 　例えば，
> 
>  blocking_region{
>    data = read(...)
>  }
> 
>  とあったとき，data が到達しているのならば，割り込んで欲しくないはずで
> ある．ただし，data が到達する前に割り込みで中断していれば，CHECK_INTS()
> により例外を発生させるべきである．この判断は rb_bocking_region() 利用者
> しかできないので，その判断をさせるべきである．
> 
> 
> 参考文献：
> [1] Akira Tanaka "Re: Thread#raise, Thread#kill, and timeout.rb are
> unsafe" ruty-talk (2008.3)
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/294917
> 
> 
> 謝辞：
> 　この議論は，3/11 10:00から開催されたRuby開発者会議で行われました．参加
> 者は田中さん，nahi さん，たるいさん，mrkn さん，skype 越しに小崎さん，中
> 田さん，sora さん，遠藤さんでした．朝もはよからありがとうございました．
> 
> -- 
> // SASADA Koichi at atdot dot net
> 
>