Reliable and Unreliable Signals
The original UNIX signal handling design using signal(3) contained a race condition. When a signal was caught by a program, the signal's registered action reverted to its default. To maintain the same registered action, the signal handler was forced to immediately re-register its required action. This left a small window of opportunity for the default action to be exercised by bad timing. This is why the signal(3) API is considered unreliable.
A new set of functions, including the function sigaction(2), has been added to the list of system calls. These form the reliable signals API. All new program development should use this API set. However, when the signal(3) API is discussed next, you will see that there are still a few cases where the older API can be used for its simplicity.
Note
BSD release 4.3 and later do not implement the System V behavior of changing the registered action to SIG_DFL. Consequently, the FreeBSD 3.4 release does not exhibit a race condition.
Registering the actions SIG_DFL and SIG_IGN can be done safely with the function signal(3). However, you should avoid the signal(3) function otherwise.