[ruby-dev:11150] Re: SIGINT on windows

なかだです。

  遅くなりました。金曜の夜にいきなり会津塩川とか遊びに行っちゃっ
たりしたもんで。

At Sat, 7 Oct 2000 00:27:29 +0900,
Daisuke Aoki <[e-mail]> wrote:
> > > Windows 95 だと ReadFile() 時の Ctrl-C の処理に限って
> > > CriticalSection がらみでタイミング上のデッドロックが生じます。
> > > LeaveCriticalSection() の後に Sleep(0) を入れるとちょっとは大丈夫に
> > > なりますが。
> >   Sleep(0) でマシになるということは、デッドロックというよりは
> > signal thread に CPU を食われてしまって処理が進まない、というこ
> > とでしょうか。
> メインスレッドで win32_call_handler() で
>  SetEvent(h->handshake) した後、シグナルスレッドに処理が移って
> win32_main_context() の WaitForSingleObject(interrupt_done, INFINITE)
> が終わって、 次の RUBY_CRITICAL() の EnterCriticalSection() で
> 待機中に、メインスレッドに処理が移らないでデッドロックが生じて
> いるようです。SetThreadContext() により何かおかしくなってこうなる
> のではないかと思いますが、原因と動作自体も不明です。

  Sleep(0) で「ちょっとは大丈夫」というのはどのくらいでしょう。
大体大丈夫になるとか、ないと全然だけどあればたまにうまく行くこ
ともあるとか。

> とにかく、win32_main_context() の２番目の RUBY_CRITICAL() で
> 頻繁にデッドロックが生じます。デバッグのために、printf とか入れると
> デッドロックしないなったりします。
> LeaveCriticalSection() の後に Sleep(0) というのは、かなり
> パフォーマンスに影響を与えるので採用できませんし。

  win32_disable_interrupt() に Sleep(0) を入れてしまうと相当に
遅くなるようです。signal 処理中だけにして win32_main_context()
と win32_call_handler() の RUBY_CRITICAL() の後だけ Sleep(0) す
るようにするのではうまくいかないんでしたっけ。

> > > あんま長い処理を CriticalSection の機構で挟むこと
> > > 自体ちょっと・・・(^^;;
> >   えー、だって OS 自体クリティカルなんだもん(笑)。
> 長く何が起こるかわからない処理の場合は Semaphore の方がまだ安全
> なので。私が CriticalSection を好きでないという理由でしかない
> かもしれませんが、一応腸、書いておくと、
> CriticalSectionを所持していないスレッドが LeaveCriticalSection()
> するとその後に、EnterCriticalSection() するとデッドロックになるとか、
> CriticalSectionを所持しているスレッドが解放せずに死ぬと、
> Win9x 系では CriticalSection は所持したままになるとか・・・
> もう回避できない問題ありっまくり(^^)

  このへんは使う側のバグもありますよね、基本的には。それに現状
の Ruby では main thread 以外は signal thread だけなはずなので
何とかなりそうな気がしますが。

> > > 後、sleep 時(win32_sleep())に Ctrl-C すると
> > > 致命的な状況になります。
> >   これは以前出た CPU 食いまくり状態と同じでしょうか。NT だと
> > ruby -e sleep でもきちんと rescue までできるんですがねぇ。
> 違います。完全に OS が逝っちゃいます(^^) 詳細は不明ですが
> これはデバッグできないので(^^;;;
> SIGINT を trap して sleep しているときに Ctrl-C で全画面モードで
> エラー表示、そのままお亡くなりになられます＞ Windows 95

  これは Win95 のバグなのかなぁ、signal thread から SetEvent()
できないというわけではなさそうだし…。ていうか同期処理すらでき
なかったら signal あっても何の役にも立たないし。具体的にどこま
でいって落ちるとかは分からないでしょうか。

> >   最初そうしてたんですけど(めんどくさかったから)、マルチプログ
> > ラミングにはロックの粒度を下げた方がパフォーマンス的にはメリッ
> > トがあるのでは。と思ったけど、結局今のところ native thread とし
> > ては単一なのでデメリットにしかなりませんか。
> ちょっと起動が遅くなったんではないかなと思ったものでして。
> 致命的な状況を回避するためならいいんですが、trap を使用している
> とき(デフォルトの signal の処理にすぐ exit() する場合以外）だけ、
> EnterCriticalSection() というのでもいいと思います。

  若干遅くなってる可能性はあります、たしかに。しかし基本的に
malloc() が HeapAlloc() を呼んでたりする以上、クリティカルなの
は間違いないようです。GC が起きていると思われるときに Ctrl+C す
ると落ちるというのがなくなりましたし、現に。

> >   考えてみたら #ifdef NT で Windows 95 まで括り込もうというのが
> > 根本的に間違ってるような気もして来ました。
> > #if defined(NT)
> > #elif defined(WIN95)
> > #endif
> > という形にならなきゃおかしいのかも、そもそも。
> #if ではなくて、
> if(IsWin95()){ or if(IsWinNT()){
> } else {
> }
> という感じがいいのではないでしょうか。

  そうですね。たしかに動的な判断でないとまずいかも。

> NT の方で落ち着いたら
> この点について私が作業しますという感じで（ここまで踏み込んだので
> しなければいけないかなということで(;_;)。その場合、一応、私が
> 作業するのに一週間ぐらい掛かると見込んでください。ただ、sleep 時の
> 問題が私に解決できるのかは自身がありません(^^;;

  一応私が作業してる NT4.0 SP5 では落ち着いてますんで、心置きな
くどうぞ(^^)。

> >   多くの unixen ではソースレベルの互換性はあるけどバイナリ互換
> > 性はない。Windowses ではバイナリフォーマットの互換性はあるけど
> > ソースレベルの互換性はない、とか。
> バイナリは一緒にしておく方がベターだと思います。NT 版と 9x 版を
> バイナリを分けて使用するのは、ユーザーとしても面倒でしょう。
> 問題は、SIGINT だけなんですし。

  NT と 95/98 は全く別個の OS だと思うんですが、半端にバイナリ
互換なところが却って厄介というか迷惑というか。

> ＃ひょっとして、うちが NEC Windows 95 だということがちと問題
> ＃だったりすると嫌ですねぇ(^^;;;;

  他の Windows 環境(NT 系 / 9x 系ともに)での動作状況が知りたい
とこです。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦