移植性¶

移植性のある signal() の使い方は、シグナルの処理方法を SIG_DFL か SIG_IGN に設定する方法だけである。 シグナル・ハンドラを設定するのに signal() を使ったときの動作はシステムにより異なる (POSIX.1 は明示的にこの違いを認めている)。 移植性が必要なときはこのシステムコールを使用しないこと。

POSIX.1 は、 sigaction(2) を規定することで移植性に関する混乱を解決した。 sigaction(2) はシグナル・ハンドラが起動される際の挙動を明示的に制御できる。 signal() の代わりにこのインターフェイスを使うこと。

オリジナルの UNIX システムでは、 signal() を使って設定されたハンドラがシグナルの配送により起動されると、 そのシグナルの処理方法は SIG_DFL にリセットされ、システムは同じシグナルがさらに生成されても シグナルの配送をブロックしなかった。これは、以下のフラグで sigaction(2) を呼び出すのと等価である。

sa.sa_flags = SA_RESETHAND | SA_NODEFER;

System V でも、 signal() に対してこれらの挙動を規定している。 こうした挙動はまずく、ハンドラがハンドラ自身を再設定する機会が 来るより前に、同じシグナルがまた配送される可能性がある。 さらに、同じシグナルが立て続けに配送されると、同じシグナルが ハンドラを繰り返し起動されることになる。

BSD improved on this situation, but unfortunately also changed the semantics of the existing signal() interface while doing so. On BSD, when a signal handler is invoked, the signal disposition is not reset, and further instances of the signal are blocked from being delivered while the handler is executing. Furthermore, certain blocking system calls are automatically restarted if interrupted by a signal handler (see signal(7)). The BSD semantics are equivalent to calling sigaction(2) with the following flags:

sa.sa_flags = SA_RESTART;

Linux での状況は以下の通りである。

• カーネルの signal() システムコールは System V 方式を提供している。
• デフォルトでは、glibc 2 以降では、 signal() ラッパー関数はカーネルのシステムコールを起動しない。 代わりに、ラッパー関数は BSD 方式を示すフラグを使って sigaction(2) を呼び出す。 機能検査マクロ _BSD_SOURCE を定義していれば、このデフォルトの動作となる。 デフォルトでは、 _BSD_SOURCE が定義される。 _BSD_SOURCE は _GNU_SOURCE が定義された場合には暗黙のうちに定義され、 もちろん明示的に定義することもできる。

  glibc 2 以降では、機能検査マクロ _BSD_SOURCE が定義されていなければ、 signal() は System V 方式となる。 (gcc(1) が標準指定モード (-std=xxx or -ansi) で起動された場合、もしくは _POSIX_SOURCE, _XOPEN_SOURCE, _SVID_SOURCE といった他の様々な機能検査マクロが定義された場合、 デフォルトの _BSD_SOURCE の暗黙の定義は行われない。 feature_test_macros(7) を参照のこと。)

• Linux の libc4 と libc5 の signal() 関数は System V 方式である。 libc5 システムにおいて <signal.h> のかわりに <bsd/signal.h> をインクルードすると、 signal() は __bsd_signal() に再定義され、 signal() は BSD 方式となる。