From: SASADA Koichi <ko1@...>
Date: 2012-06-25T21:01:55+09:00
Subject: [ruby-dev:45821] Re: 非同期割り込みに対する対処案（日本語版）

　ささだです．

　早速の回答，ありがとうございます．

　(1) はコメントとして書いておこう．

(2012/06/25 20:32), Tanaka Akira wrote:
> ブロックする操作やそれ以外の場所を safe point とするかどうかを制御する感じに
> だったように思います。

　それ以外の場所を safe point にする API が不足しているでしょうか？（私
の見落とし？）

　具体的には，Thread.delay_interrupt の逆．


>> 　あと，よくよく考えると，Thread.blocking_uninterruptible などで，klass
>> の指定が n 個ネストすると，非同期割り込みが起こる度に n 回チェックする必
>> 要がある気がします．包含関係があるので，単純にそうではないんですが．継承
>> 関係を考えると，ハッシュで O(1)，というわけにもいかない（飛んできた例外
>> オブジェクトの継承木の高さが m 個の場合，O(m) でいけるか）．
> 
> そうですね。
> 
>> 　また，[ruby-talk:294917] ではキューで管理するべき，ということでした
>> が，種類によって割り込みが追い越す可能性があります（例えば，TimeoutError
>> がブロックされており，キューに貯まっているとき，InterruptError が来たら
>> どうなるか）．
> 
> 追い越すのではないかと思います。
> 
>> (5) チェックのコストをどう考えるか（O(m) は甘受すべきコストか）
> 
> 非同期イベントはそのコストが問題になるほど頻繁に使うべきものではないんじゃないでしょうか。
> 
> 原則的には、プロセスの終了のためにのみ使うべきだと思っています、

　つまり，このキューは殆どの場合空であるため，もしくは空にするべきである
ため，コストに関してはあまり気にならないんじゃないの，ということですね．


>> (6) 追い越しが発生するとき，どうすると良いか
> 
> 追い越せばいいんじゃないでしょうか。
> なにを問題と感じているのかわかりません。

　何かの弾みでキューに例外が詰まってきたとき，ナイーブに作るとかなりオー
バヘッドがかかりそうだなぁ，と思ったんですが，気合い入れて結果をきちんと
キャッシュすればなんとかなるかな...．


>> 　あと，[ruby-talk:294917] では "It is because Thread.check_interrupt
>> with blocking operations causes race conditions." と，race が起こるとか
>> いてあるんですが，これどういう話でしたっけ．
> 
> あぁ、race もありますが、もっとあからさまにブロックしている最中に
> 中断できなければならないというほうがわかりやすい必要性かもしれません。
> 
> race は、ブロックする直前や直後にシグナルが来たときの話を想定していました。
> もし Binary Hacks を持っているなら「sigsafeでシグナル処理を安全にする」という
> のを読んでみてください。

　なるほど，その話でしたか．了解です．

-- 
// SASADA Koichi at atdot dot net