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

(2012/06/26 4:44), KOSAKI Motohiro wrote:
>> の３つになるような気がしていますので，ある例外がこれら 3 つのどの状態に
>> するか，という API を考えてみました．
>>
>>  (a) Thread.interrupt_mask(exception, state) do; end
>>  (b) Thread.interrupt_mask(hash) do; end
> 
> (b)のほうは指定した全ての変更がアトミックに切り替わらないと絶対文句が出るAPIだと思うのですが、はたしてそんなことが可能でしょうか

　C で書く API だから，atomic に変わります．

> また、blocking_interruptibleのときが、pthread cancel モデルなのであれば、
> 自発的に例外を確認する pthread cancel() 関数相当のメソッドが必要だと思います

　それを忘れていました．要するに例外が届いているかチェックするメソッドで
すよね．Thread.check_ints() としておこう（名前はとりあえず適当です）．

>> :immediate_interruptible
>> :blocking_interruptible
>> :uninterruptible
> 
> メソッド名と引数の両方に interruptの単語が入っているのはやや冗長ではないでしょうか

　冗長だというのに同意します．が，とりあえず挙動を議論したいので，そのま
まで．名前はもうちょっと後で．

>> (1) シグナルを許すと言っても，SIGUSR1 とかも許していいのかな．
> 
> シグナル毎に違うExceptionを投げるべきだと思います。全部SignalExceptionの
> サブクラスにすれば既存のコードで動くんじゃないでしょうか

　これは，ちょっと off topic ですかね．


>> (2) POSIX みたいに，このメソッドは blocking とか，すべてきちんと
>>   書き連ねる必要があるのかな．かなり，無理な気がする
>> 　（そもそも，何がどのメソッドを呼び出すかわからない気が）．
> 
> 当面GVL離すところで、チェックするようにして、GVL離すタイミングを
> 徐々に増やしていくとかですかね。

　ここは，ドキュメントの話をしていたつもりです．

　増やしていくと嬉しいことがある？

>> (3) ライブラリの至る所でこんなの書かれたらハッシュが大量発生して，
>>   オーバヘッドで大変になったりしないだろうか...．
>>   そもそも，これって多用するんだろうか．
> 
> わたしの想定は、１行目で blocking_interruptible にして二度と変えない。
> ensureの中でIOを呼ぶときだけ一時的に uninterruptibleに変更
> 
> 
>> (4) ブロックを持たない Thread.mask_interrupt() は許すべきだろうか．
>> 　（意味としては，「この呼び出し以降はこの設定で」，という感じ）
>>   なんとなく，許さない方がいいような気がするんだけど
> 
> (3)とあわせてブロック必須だと全プログラムが一段ネストが深くなるので
> うれしくないなあ

　ここは，誰か偉い人にデザインを任せたいところなんですが...．


>> (5) Thread.mask_interrupt() はネストしたら設定を混ぜていく，としたけど
>>   単に，置き換える，という選択肢もあるのか．こっちのほうが使いやすい？
> 
> 混ぜていく。というのがなにを指しているのか取れなかったので置き換えるモデルで動作例を書いていただけるとうれしいです

　置き換える例について，先のコード例ですと，

  Thread.interrupt_mask(param1) do
    Thread.interrupt_mask(param2) do
      # block
    end
  end

では，混ぜていく場合は block では param1 & param2 が効きますが，置き換え
る場合とは，これを param2 *しか* 効かなくするのはどうだろう，ということ
です．外側は一切見ない．

　これだと，ハッシュを使い回すというか，よくやる「akr が薦めるだいたい安
全セット」「kosaki 認定絶対安全セット」みたいなのを作ってそれを使う様に
すると，毎回 Hash を作らなくなって，よくなるかも．


# あと，実装はこっちのほうが楽なんすよね...．

-- 
// SASADA Koichi at atdot dot net