4.2 Signal Handling

A signal is a form of software interrupt to the normal execution of a user process. Signals occur as a result of a variety of events, including any of the following:

• Typing Ctrl/C at a terminal

• Certain programming errors

• A call to the gsignal or raise function

• A wake-up action

4.2.1 OpenVMS Versus UNIX Terminology

Both OpenVMS and UNIX systems provide signal-handling mechanisms that behave differently but use similar terminology. With the DEC C RTL, you can program using either signal-handling mechanism. Before describing the signal-handling routines, some terminology must be established.

The UNIX term for a software interrupt is signal. A routine called by the UNIX system to process a signal is termed a signal handler.

A software interrupt on an OpenVMS system is referred to as a signal, condition, or exception. A routine called by the OpenVMS system to process software interrupts is termed a signal handler, condition handler, or exception handler.

To prevent confusion, the terms signal and signal handler in this manual refer to UNIX interrupts and interrupt processing routines, while the terms exception and exception handler refer to OpenVMS interrupts and interrupt processing routines.

4.2.2 UNIX Signals and the DEC C RTL

Signals are represented by mnemonics defined in the <signal.h> header file. Table 4-3 lists the supported signal mnemonics and the corresponding event that causes each signal to be generated on the OpenVMS operating system.

Table 4-3 DEC C RTL Signals

By default, when a signal (except for SIGCHLD) occurs, the process is terminated. However, you can choose to have the signal ignored by using one of the following functions:

You can have the signal blocked by using one of the following functions:

Table 4-3 indicates those signals that cannot be ignored or blocked.

You can also establish a signal handler to catch and process a signal by using one of the following functions:

Unless noted in Table 4-3, each signal can be reset. A signal is reset if the signal handler function calls signal or ssignal to re-establish itself to catch the signal. Example 4-1 shows how to establish a signal handler and reset the signal.

The calling interface to a signal handler is:

void handler (int sigint);

Where sigint is the signal number of the raised signal that caused this handler to be called.

A signal handler installed with sigvec remains installed until it is changed.

A signal handler installed with signal or signal remains installed until the signal is generated.

A signal handler can be installed for more than one signal. Use the sigaction routine with the flag SA_RESETHAND to control this.

4.2.3 Signal-Handling Concepts

A signal is said to be generated for (or sent to) a process when the event that causes the signal first occurs. Examples of such events include detection of hardware faults, timer expiration, and terminal activity, as well as the invocation of kill. In some circumstances, the same event generates signals for multiple processes.

Each process has an action to be taken in response to each signal defined by the system. A signal is said to be delivered to a process when the appropriate action for the process and signal is taken.

During the time between the generation of a signal and its delivery, the signal is said to pending. Ordinarily, this interval cannot be detected by an application. However, a signal can be blocked from delivery to a process:

• If the action associated with a blocked signal is anything other than to ignore the signal, and if that signal is generated for the process, the signal remains pending until either it is unblocked or the action associated with it is set to ignore the signal.

• If the action associated with a blocked signal is to ignore the signal and if that signal is generated for the process, it is unspecified whether the signal is discarded immediately upon generation or remains pending.

Each process has a signal mask that defines the set of signals currently blocked from delivery to it. The signal mask for a process is initialized from that of its parent. The sigaction, sigprocmask, and sigsuspend function control the manipulation of the signal mask.

The determination of which action is taken in response to a signal is made at the time the signal is delivered, allowing for any changes since the time of generation. This determination is independent of the means by which the signal was originally generated. If a subsequent occurrence of a pending signal is generated, it is implementation-dependent as to whether the signal is delivered more than once. The DEC C RTL delivers the signal only once. The order in which multiple, simultaneously pending signals are delivered to a process is unspecified.

4.2.4 Signal Actions

This section applies to the sigaction, signal, sigvec, and ssignal functions.

There are three types of action that can be associated with a signal:

Initially, all signals are set to SIG_DFL or SIG_IGN prior to entry of the main routine (see the exec functions.) The actions prescribed by these values are:

4.2.5 Signal Handling and OpenVMS Exception Handling

This section discusses how DEC C RTL signal handling is implemented with and interacts with OpenVMS exception handling. Information in this section allows you to write OpenVMS exception handlers that do not conflict with DEC C RTL signal handling. For information on OpenVMS exception handling, see the VAX Procedure Calling and Condition Handling Standard.

The DEC C RTL implements signals with OpenVMS exceptions. When gsignal or raise is called, the signal number is translated to a particular OpenVMS exception, which is used in a call to LIB$SIGNAL. This mechanism is necessary to catch an OpenVMS exception resulting from a user error and translate it into a corresponding UNIX signal. For example, an ACCVIO resulting from a write to a NULL pointer is translated to a SIGBUS or SIGSEGV signal.

Tables 4-4 and 4-5 list the DEC C RTL signal names, the corresponding OpenVMS VAX and OpenVMS Alpha exceptions, the event that generates the signal, and the optional signal code for use with the gsignal and raise functions.

Table 4-4 DEC C RTL Signals and Corresponding OpenVMS VAX Exceptions (VAX only)

To call a signal handler that you have established with signal or sigvec, the DEC C RTL intercepts the OpenVMS exceptions that correspond to signals by having an OpenVMS exception handler in the main routine of the program. If your program has a main function, then this exception handler is automatically established. If you do not have a main function, or if your main function is written in a language other than DEC C, then you must invoke the VAXC$CRTL_INIT routine to establish this handler.

The DEC C RTL uses OpenVMS exceptions to implement the setjmp and longjmp functions. When the longjmp function is called, a C$_LONGJMP OpenVMS exception is signaled. To prevent the C$_LONGJMP exception from being interfered with by user exception handlers, use the VAXC$ESTABLISH routine to establish user OpenVMS exception handlers instead of calling LIB$ESTABLISH. The C$_ LONGJMP mnemonic is defined in the <errnodef.h> header file.

If you want to use OpenVMS exception handlers and UNIX signals in your C program, your OpenVMS exception handler must be prepared to accept and resignal the OpenVMS exceptions listed in Tables 4-4 (VAX only) and 4-5 (Alpha only), as well as the C$_LONGJMP exception and any C$ facility exception that might be introduced in future versions of the DEC C RTL. This is because UNIX signals are global in context, whereas OpenVMS exceptions are stack-frame based.

Consequently, an OpenVMS exception handler always receives the exception that corresponds to the UNIX signal before the DEC C RTL exception handler in the main routine does. By resignaling the OpenVMS exception, you allow the DEC C RTL exception handler to receive the exception. You can intercept any of those OpenVMS exceptions yourself, but in doing so you will disable the corresponding UNIX signal.

Table 4-5 DEC C RTL Signals and Corresponding OpenVMS Alpha Exceptions (Alpha only)

OpenVMS Alpha Signal-Handling Notes (Alpha only)

• While all signals that exist on OpenVMS VAX systems also exist on OpenVMS Alpha systems, the corresponding OpenVMS exceptions and code is different in a number of cases because on Alpha processors there are two new OpenVMS exceptions and several others that are obsolete.

• All floating-point exceptions on OpenVMS Alpha systems are signaled by the OpenVMS exception SS$_HPARITH (high-performance arithmetic trap). The particular type of trap that occurred is translated by the DEC C RTL through use of the exception summary longword, which is set when a high- performance arithmetic trap is signaled.

• Since the SS$_COMPAT, SS$_TBIT, and SS$_RADMOD exceptions are never reported on OpenVMS Alpha systems, they are not recognized by the DEC C RTL on OpenVMS Alpha systems. Since each signal that corresponds to one of these exceptions also corresponds to another OpenVMS exception as well, all the signals are shown in Table 4-5.