Provided by: manpages-ja-dev_0.5.0.0.20131015+dfsg-2_all 
名前
signal - ANSI C シグナル操作
書式
#include <signal.h>
typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t sighandler);
説明
signal() の動作は UNIX のバージョンにより異なる。 また、歴史的に見て Linux のバージョンによっても異なっ
ている。 このシステムコールの使用は避け、 代わりに sigaction(2) を使用すること。 下記の「移植性」を参
照。
signal() はシグナル signum の処理方法を handler に設定する。 handler には、 SIG_IGN、 SIG_DFL、 プログラ
マが定義した関数 (「シグナル・ハンドラ」) のアドレスの いずれかを指定する。
シグナル signum がプロセスに配送されると、以下のいずれかが発生する。
* 処理方法が SIG_IGN に設定されている場合、そのシグナルは無視される。
* 処理方法が SIG_DFL に設定されている場合、シグナルに関連づけられた デフォルトの動作が行われる
(signal(7) 参照)。
* 処理方法として関数が設定されている場合、 まず最初に処理方法が SIG_DFL にリセットされるかそのシグナルの
ブロックが実行された後、 signum を引き数として handler が呼び出される。 ハンドラが起動される際にシグナ
ルがブロックされた場合、 ハンドラが返る際にそのシグナルのブロックが解除される。
シグナル SIGKILL と SIGSTOP は捕捉できず、無視することもできない。
返り値
signal() は、今までのシグナル・ハンドラの値を返す。 エラーの場合は SIG_ERR を返し、 errno にエラーの原因
を示す値を設定する。
エラー
EINVAL signum が不正である。
準拠
C89, C99, POSIX.1-2001.
注意
マルチスレッドプロセスにおける signal() の結果は、指定されていない。
POSIX では、 kill(2) や raise(3) で生成できないシグナル SIGFPE, SIGILL, SIGSEGV を無視 (ignore) した場
合、その後の動作は未定義である。 ゼロによる整数割り算の結果は未定義となる。 アーキテクチャーによって
は、このとき SIGFPE シグナルが生成される。 (同様に負の最大整数を -1 で割ると SIGFPE が生成されるかもしれ
ない) このシグナルを無視すると無限ループに陥るかもしれない。
SIGCHLD の動作として SIG_IGN を設定した場合の詳細な動作については、 sigaction(2) を参照すること。
シグナル・ハンドラ内から安全に呼び出すことができる、 async-signal-safe functions (非同期シングルで安全な
関数) の リストについては signal(7) を参照。
sighandler_t の使用は GNU 拡張であり、 _GNU_SOURCE が定義された 場合に公開される。glibc では _BSD_SOURCE
が定義された場合には (BSD 由来の) sig_t も定義される。このような型を使用しないと、 signal() の宣言は読み
にくいものとなる。
void ( *signal(int signum, void (*handler)(int)) ) (int);
移植性
移植性のある 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 はこの状況が改善したが、残念なことに、その過程で既存の signal() の挙動も変更された。 BSD では、シグナ
ルハンドラが起動された際、 シグナルの処理方法はリセットされず、 ハンドラの実行中は、同じシグナルのさらな
る生成は配送がブロックされる。 また、 シグナルハンドラが中断された場合、 停止中のシステムコールのいくつか
は自動的に再スタートされる。 BSD の挙動は、 以下のフラグを指定した sigaction(2) の呼び出しと等価である。
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 方式となる。
関連項目
kill(1), alarm(2), kill(2), killpg(2), pause(2), sigaction(2), signalfd(2), sigpending(2),
sigprocmask(2), sigsuspend(2), bsd_signal(3), raise(3), siginterrupt(3), sigqueue(3), sigsetops(3),
sigvec(3), sysv_signal(3), signal(7)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.54 の一部 である。プロジェクトの説明とバグ報告
に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。