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

なかだです。

At Wed, 15 Nov 2000 23:31:53 +0900
> 止まってしまう時の状況をちゃんと調べてみました。
> 
> SIGNAL: win32_main_context() の１番目の RUBY_CRITICAL に入る。
> MAIN:   win32_enter_syscall() の win32_disable_interrupt() で止まる。
>           SuspendThread() で止まっていないケース。
> SIGNAL: win32_main_context() で MAIN を SetThreadContext() で操作。MAIN が動く。
> SIGNAL: win32_main_context() の１番目の RUBY_CRITICAL から出る。
> MAIN:   win32_call_hander() の RUBY_CRITICAL に入る。
> MAIN:   win32_call_hander() の RUBY_CRITICAL から出る。
> SIGNAL: win32_main_context() の２番目の RUBY_CRITICAL に入ろうとするが止まる。
> 
> という感じで、EnterCriticalSection() で止まっているスレッドに、
> SetThreadContext() で操作しているしたのが原因？で win32_enter_syscall() の
> win32_disable_interrupt() で CriticalSection を獲得してないはずなのになぜか
> 獲得したことになってて、win32_main_context() の２番目の RUBY_CRITICAL に入ることが
> できずデッドロックしてしまうみたいです。

  あーなるほど。EnterCriticalSection()も Win95 では中断不可のシステムコー
ルだということですね。自前で同期してやるしかありませんか、やっぱり。

  しかし、今のコードだと SetThreadContext() されるときというのはほとんど 
Sleep(1) の中になると思うんですが、Sleep() は中断しても大丈夫なんでしょ
うか。WaitFor* が大丈夫なら結構手だてはありそうなんですが…。

> で、２行目の MAIN: win32_enter_syscall() の win32_disable_interrupt() がないケースでは
> デッドロックしていません。これは、rb_io_gets() 内のような win32_leave_syscall() の
> 後に win32_enter_syscall() がすぐ呼ばれるようなケースで起きやすいです。

  win32_leave_syscall() で実行を許可された SIGNAL の方が、MAIN が 
win32_enter_syscall() に入るより先に SuspendThread() してるんでしょうね、
これは。

> 前、win32_main_context() で SetThreadContext() 使って操作する前に、
> メインスレッドで win32_enable_interrupt() でトップレベルまで戻ったときに、
> ループで止めるという仕組みをつくって試したことがあったのですが、最終的にはそういうことを
> しないと同期 API で止まっている状況を完全に防ぐことはできなさそうですね。

  トップレベルまで戻るというのは?

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