From: keiju@... (=?ISO-2022-JP?B?GyRCQFBETTc9PHkbKEI=?= )
Date: 1998-04-14T09:26:15+09:00
Subject: [ruby-dev:2293] Re: [Problem] thread and signal and sleep

けいじゅ＠日本ラショナルソフトウェアです.

In [ruby-dev :2282 ] the message: "[ruby-dev:2282] Re: [Problem]
thread and signal and sleep ", on Apr/13 16:47(JST) Yukihiro Matsumoto
writes:

>まつもと ゆきひろです

>|でも, さっきの例だと, 2つのスレッドがあって1つはstopしていて, もう1つ
>|がsleepしていてカレントスレッドがない状態ですよね? その場合はどのよう
>|にスレッドを選ぶんですか? きっと, main_threadが受けていますよね? この
>|時最後のカレントスレッドがシグナルを受けとれると, 非常に嬉しいんですけ
>|ど...
>
>まず，動いているスレッドがなくてもカレントスレッドはあります．
>それにrubyのスレッドの場合，一見stopしているようでもbusy
>waitしている場合もありますし，一般的にはなかなかうまくいかな
>いんではないかと思います．


>|うーん. これがですね.... 今のirbなんかはmain_threadが必ず受けるという
>|ふうになるとかなりの仕様変更になっちゃうんですよね(^^;;;
>
>はあ，すいません．ただ「不定」なものに立脚してプログラムしちゃ
>うと後々つらいんではないでしょうか？

確かに, ここが甘かったんですけど(^^;;; 

それはともかく, main_threadで受ければいいかというと場合によりけりです
よね. 

ほとんどのシグナルは, 内部的な原因によるもので, それらのシグナルは実際
にその原因となった命令を実行したスレッドで受けとりたいことが多いはずで
すよね. または, 実際にどのスレッドで実行したか知りたいことが多いと思い
ます.

また, 

  SIGHUP
  SIGINT
  SIGQUIT
  SIGKILL

などは, 外的な要因なのでカレントスレッドが受けとれば良いというものでも
ない気がします.

例えば, irbではアクティブになっているサブirbが必ず1つだけ存在している
ので, そのサブirbを起動しているスレッドでシグナルを受けとりたいわけで
すね. 

>|でも, ちゃんとマルチスレッドで例外を管理するには, 必ずmain_threadが受
>|けるとなっている方が楽でしょうから, Thread.abort_on_exception見たく選
>|べると良いですね.
>
>これは採用しません．できるだけ実行状態にモードがあるのは避け
>たいんです．Thread.abort_on_exceptionはデバッグ用として例外
>であると思ってます．

そうですか...

これから提案するのはもっとすごいんですが.... でも, モードでもないから
いいかな...

1. デフォルトの動作はカレントスレッドが受ける. 
2. メインスレッドに限らずシグナルを受けるスレッドが指定できる.

  Thread.catch_signal = thread

3. 指定はprocでも可能.

  Thread.catch_signal = proc{|sigtype, currentThread| ...}

  その場合は, 引数としてシグナルタイプとその時のカレントスレッドを引き
渡す. procの戻り値のスレッドに対してシグナルを送る. 

#このprocを実行するスレッドがその時のカレントスレッドと同じになるなら,
#currentThreadは渡す必要はありません.

__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: keiju@rational.com <<---