critical impact:

signal function - behavior difference (CrCh18)

Problem description

The behavior for the signal function is different on Tru64 UNIX and HP-UX.

HP-UX follows the traditional System V unreliable signal behavior. This differs from the default Tru64 UNIX behavior in the following ways:

• On HP-UX, just before the signal handler is invoked, the action for the signal is reset to SIG_DFL. On Tru64 UNIX, the action is not reset. As a result, only the first signal is caught on HP-UX. Depending on the signal's default action, later signals are either ignored or terminate the process.

• On HP-UX, while the signal handler is executing, other occurrences of the signal are not blocked. On Tru64 UNIX, the other occurrences are blocked. Because of this, you cannot solve the first problem by adding the following statement to the beginning of the signal handler:

  signal(sig, sighandler);

  There is a small window between when the signal handler is invoked and when the statement is actually executed when a second signal could arrive. That signal would trigger the default action and thus either be ignored or terminate the process.

When an application is built in the System V Habitat on Tru64 UNIX, signal follows the HP-UX behavior.

When an application is linked with libbsd on Tru64 UNIX, some system calls are automatically restarted when they are interrupted by the signal handler. They are not restarted with the default Tru64 UNIX signal function or the HP-UX signal function.

Identifiers

signal

See also

• Background information on signal specific issues impacts
• sigaction(2)
• signal(2)
• standards(5)

Solution description

Use the sigaction function.

New behavior

struct sigaction sa;
sa.sa_handler = handler;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
#ifdef _BSD
sa.sa_flags |= SA_RESTART;
#endif
if (sigaction(SIGCHLD, &sa, NULL) < 0)
        perror("sigaction");

See also

• sigaction(2)
• signal(2)

Problem summary