Signals

Supported Signal Functions

All signal functions defined by the POSIX.1 standard are implemented in the POSIX/iX library. While the ANSI C functions signal() and raise() are provided in the POSIX/iX library, they are not part of the POSIX.1 standard. A strictly conforming POSIX application should not use them.

Signal Descriptions

Table 3-6 “POSIX/iX Signals” describes the signal constants declared in the <signal.h> header that are used by a process to refer to the signals that occur on the system. Also noted are the default action taken by the system when the signal is delivered, whether the signal is required for POSIX.1 conformance, and any MPE/iX implementation details.

Additional Implementation Considerations

On MPE/iX, signals cannot be delivered to a process while that process is executing system code. The signal remains pending until control returns to the calling process. A sending process cannot rely on timely delivery of a signal if the target process is executing system code. For example, if a signal is generated for a process when the process is executing a call to read() or write(), the signal remains pending until the function call returns either after successful transfer of data or when an error is encountered.

The ANSI C signal() function is implemented in the POSIX/iX library as a call to sigaction(); however, the signal() function is considered by the POSIX.1 standard to be incompatible with the POSIX.1 sigaction() function. A strictly conforming POSIX.1 application must not use the signal() function.

The sigaction() function can return and reinstall a signal action that was originally installed by signal(); however, the structure that sigaction() returns in oact cannot be reliably examined by the calling process. If this same signal action is later reinstalled, without modification, by another call to sigaction(), the result is as if the original call to signal() were repeated.

If multiple occurrences of a signal are generated while that signal is blocked and pending, each occurrence of the signal is left pending. If the signal is later unblocked, multiple instances of that signal can be delivered to the process.

A signal that is both blocked and ignored for a calling process remains pending if generated. Calls to the sigpending() function return signals that are both blocked and ignored. When the signal is no longer blocked, it is discarded when delivery is attempted.

Setting SIGCHLD to SIG_IGN has no effect on the operation of the wait() and waitpid() functions. A strictly conforming POSIX.1 application must not set the action associated with SIGCHLD to SIG_IGN.

When using the kill() function, the value -1 is not a valid value for passing to the pid parameter. If a -1 is passed in the pid parameter, kill() returns an error and sets errno to EINVAL.

On MPE/iX, a process's real user ID, effective user ID, and saved set-user-ID are always identical. In addition, {SAVED_SET_IDS} is always defined.

If the sigmask parameter of the sigsuspend() function is set to NULL, the process is suspended with the current signal mask. This implementation is considered an extension to the POSIX.1 standard. A strictly conforming POSIX application should pass in the sigmask parameter of the sigsuspend() function the current signal mask returned by a successful call to sigprocmask() where set is set to NULL.

POSIX/iX library functions that have parameters that pass or return pointers can return an error and set errno to EFAULT if a NULL or a bad address is passed.