Guardian Programmer's Guide

Debugging, Trap Handling, and Signal Handling
Guardian Programmer’s Guide — 421922-014
25 - 23
When Would You Use a Signal Handler?
When Would You Use a Signal Handler?
If your applications have trap handlers to handle trap conditions in TNS processes, you
should write signal handlers to handle the equivalent signals in native processes.
Signal handlers are also helpful in applications that must run all the time with minimal,
if any, operator intervention, such as a print spooler. A signal handler catches signals
that might cause the spooler process to terminate. Having a signal handler can
prevent the spooler process from terminating and waiting to be restarted by an
operator.
Default Signal Handlers
If what you need to do is display process context information before taking the default
action for a signal and the program is in C, consider using the default signal handler
provided by the Common Run-Time Environment (CRE). The CRE sets up a signal
handler for all signals in which the default action is not to ignore the signal.
If a C program has not set up its own signal handler, the CRE signal handler takes over
when a signal is delivered to the program. The CRE signal handler displays a
diagnostic message explaining the signal and also displays a stack trace. If the default
action for the signal was to terminate the process, the CRE signal handler calls the
PROCESS_STOP_ procedure.
The CRE does not provide a default signal handler for programs written in pTAL. To
display process context information when a pTAL process receives a signal, you can
use the HIST_INIT_, HIST_FORMAT_, and HIST_GETPRIOR_ procedures.
Standard Signals Functions
Table 25-3 shows the standard signals functions that native processes (Guardian or
OSS) can use to handle signals. Notice that native Guardian processes cannot send
or receive a signal from another process using the kill() function.