ruby-dev

山本です。

参考までに、他の処理系ではシグナルの処理を遅延させているようです。

Perl: http://perldoc.jp/docs/perl/5.8.0/perldelta.pod

  安全なシグナル

  シグナルが都合の悪い時にやって来るとPerlの内部状態が改変されてしまうという点で
  以前のPerlは壊れやすいものでした。しかし現在のPerlは安全になるまで(between opcodes)
  シグナルの扱いを引き延ばすようになりました。

  この変更は、シグナルがPerlをただちに中断させなくなったため、驚くべき副作用を持って
  いるかもしれません。現在のPerlは、最初に例えば(sort()のような)内部操作や(I/O操作のような)
  外部操作を1つ完了することによって今行っていることを終わらせ、その後にのみ
  (そして次の操作を開始する前に)受け取ったシグナルを調べます。現在の操作が必ず初めに
  終わらせられるので内部状態の改変は無くなりましたが、シグナルが効果を発揮するためには
  より多くの時間がかかるかもしれません。しかしpotentially blocking operationsからの脱出は
  今でも働くはずです。

//////////////////////////

Gauche: http://www.shiro.dreamhost.com/scheme/gauche/man/gauche-refj_127.html

  シグナルがSchemeプロセスに送られると、それはVM中のキューに入れられます。 
  VMは「安全なポイント」に達した時にキューを検査し、シグナルが届いていればそれを順に処理します。
   (このメカニズムのため、SIGILLのようなシグナルはSchemeレベルでは処理できません。
  そのシグナルをキューに入れた後でプロセスが意味のある処理を続行できないからです)。

//////////////////////////

Python: http://www.python.jp/pub/doc_jp/lib/module-signal.html

  Python のシグナルハンドラは Python のユーザが望む限り非同期で呼び出されますが、
  呼び出されるのは Python インタプリタの ``原子的な (atomic)'' 命令実行単位の間です。
  従って、 (巨大なサイズのテキストに対する正規表現の一致検索のような) 純粋に C 言語の
  レベルで実現されている時間のかかる処理中に到着したシグナルは、不定期間遅延する可能性があります。

//////////////////////////

また、

  http://www.linux.or.jp/JM/html/LDP_man-pages/man2/signal.2.html

  他の場所での処理が任意の箇所で割り込まれるため、ルーチン handler は非常に注意しなければならない。
  POSIX には「安全な関数」という概念がある。シグナルが安全でない関数に割り込み、かつ handler が
  その安全でない関数を呼び出していた場合、その挙動は未定義である。安全な関数は様々な規格に明確に
  リストされている。

とあり、シグナルハンドラで直接 ruby コードを実行するのは良くないのかもしれません。

# シグナルをキューに入れてメインスレッドで処理すれば、[ruby-dev:25716] の pthread 問題も
# プラットフォームに依存しない方法で解決できそうな気がしますが、この方法だと結局 gets が
# 返るまで interrupt できない気もします。

# Perl は最後の文で「そんなことはない」と言っているようにもみえますけど・・・