POSIX.1 は、 \fBsigaction\fP(2) を規定することで移植性に関する混乱を解決した。 \fBsigaction\fP(2)
はシグナル・ハンドラが起動される際の挙動を明示的に制御できる。 \fBsignal\fP() の代わりにこのインターフェイスを使うこと。
-In the original UNIX systems, when a handler that was established using
-\fBsignal\fP() was invoked by the delivery of a signal, the disposition of the
-signal would be reset to \fBSIG_DFL\fP, and the system did not block delivery
-of further instances of the signal. This is equivalent to calling
-\fBsigaction\fP(2) with the following flags:
+オリジナルの UNIX システムでは、 \fBsignal\fP() を使って設定されたハンドラがシグナルの配送により起動されると、
+そのシグナルの処理方法は \fBSIG_DFL\fP にリセットされ、システムは同じシグナルがさらに生成されても
+シグナルの配送をブロックしなかった。これは、以下のフラグで \fBsigaction\fP(2) を呼び出すのと等価である。
sa.sa_flags = SA_RESETHAND | SA_NODEFER;
-System V also provides these semantics for \fBsignal\fP(). This was bad
-because the signal might be delivered again before the handler had a chance
-to reestablish itself. Furthermore, rapid deliveries of the same signal
-could result in recursive invocations of the handler.
+System V でも、 \fBsignal\fP() に対してこれらの挙動を規定している。 こうした挙動はまずく、ハンドラがハンドラ自身を再設定する機会が
+来るより前に、同じシグナルがまた配送される可能性がある。 さらに、同じシグナルが立て続けに配送されると、同じシグナルが
+ハンドラを繰り返し起動されることになる。
BSD improved on this situation, but unfortunately also changed the semantics
of the existing \fBsignal\fP() interface while doing so. On BSD, when a
OSDN Git Service
