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

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

In [ruby-dev :2353 ] the message: "[ruby-dev:2353] Re: [Problem]
thread and signal and sleep ", on Apr/15 18:44(JST) Yukihiro Matsumoto
writes:

>まつもと ゆきひろです

>|>|カレントスレッドがシグナルを受けとれるというのは, それなりに分かりやす

>|元に戻すのとはちょっと違うんじゃないかな? 同じになるんです?
>|たとえば, SIGSEGVやSIGPIPEしたスレッドが確実にシグナルうけとれるんです?
>
>多分ね．というのもSIGSEGVやSIGPIPEに関しては(普通は)プログラ
>ム実行中に発生するので，コンテキストスイッチのいやらしいタイ
>ミングで発生することはあんまりないと思いますから．

なるほど. 了解しました.

>外部から与えられるシグナルが問題なんです．が，SIGPIPEにして
>も外側からraise(2)やkill(2)で与えられる可能性があるのでやや
>こしいわけです．UNIXのシグナルモデルが恨めしい．

ああ. なるほどね. いいんじゃないですかこれは?

# っていっていいんだろうか... でも, rubyに限らずCでもあるわけでしょう
# がないんでしょうね...

>|>まあ，preemptiveなスレッドの問題は解決しますが，それ以外につ
>|>いてはやっぱり問題なままじゃないですか？
>|良く理解できていないんですが, 何が問題のままなんでしょう?
>
>irbの中でThread.startが呼ばれることがあるので，シグナルが届
>くスレッドを明示的に指定する方法が旨くいかない可能性があるこ
>とのつもりなんですけど．

そうですね. カレントスレッドにシグナルを送る限り, irbにとってはいいこ
とないですが, それでもカレントスレッドがシグナルを受ける方が良いと思い
ますよ.

で, irb側で何らかの手をうたないといけないと思いますが... そのためには
rubyで何らかの機能提供があると嬉しいですが... と思いましたが...

  Thread.raise ...

した時に, 例外を受けたスレッド側の$!, $@に設定されているので, 問題ない
ことに気づきました. 

ちょっと別のことでリクエストがあります. これは別メイルで.

>|私は, シグナルを発生する原因となったオペレーションを行なったスレッドが
>|シグナルを受けるのが良いと思います. そうしないと内因的シグナルの意味が
>|ほとんどなくなるからです. ただ, 内因的なシグナル(関数に由来する)って
>|
>|  SIGILL
>|  SIGFPE
>|  SIGSEGV
>|  SIGPIPE
>|  SIGBUS
>|  SIGSYS
>|  SIGXFSZ
>|
>|ぐらいですから無視して良いといえば良いのかも知れませんが...
>
>SIGILLやSIGSEGVはrubyレベルでは発生すべきではないと思います．
>ハンドルできないようにしても構わないかなって思ってます．

extレベルでは扱うこともあるかなと... その時にext内部でtrapを設定できな
いと困りますよね.

# それとruby上のシグナル処理とは違っているなら別ですが...

>SIGFPEはrubyのモデルでは発生しないはずです．明示的にfpuを操
>作すれば別ですが．

ですね.

>SIGSYSとかSIGXFSIZってなんだっけ？

SIGSYSは良く分かりませんが, システムコール関係で引数が悪い時に発生する
んじゃないかしら? OS依存のシグナルらしいですけどね. SIGXFSZはファイル
サイズがlimitを越えた時に発生するみたいですね.

>んで，これらについての問題はこれらのシグナルが発生したからと
>言って内因性であるかどうかは判別できないことです．それはそれ
>で構わないんですか？

UNIXの本質的な問題点ですからしょうがないですよねえ... プログラム側で対
処するしかないんじゃないかしら? 同じオペレーションを2度実行するとかね...

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