Open System Services Programmer's Guide

Signals Interoperability
Signals are software interrupts that provide a way of handling asynchronous events, such as a
user at a terminal typing an interrupt key, timer expiration, detection of a hardware fault, or
abnormal termination of a process.
Using Standard Signals Functions
Both OSS processes and Guardian native processes can send, receive, and handle signals using
the functions in the OSS API, which conform to the POSIX.1 standard. However, there are some
important differences (mostly with respect to how Guardian processes interact with signals), which
are summarized as follows:
• Control of a process over itself and other processes
An OSS process can control, or send a signal to, itself using a function such as raise(),
abort(), or sleep(). An OSS process can also exercise control over another OSS process
by sending a signal to it using the kill() function.
A Guardian native process can use most of the signals functions in the OSS API to send,
receive, and handle signals but only for the purpose of exercising control over itself. A Guardian
native process cannot send a signal to or receive a signal from another Guardian or OSS
process using the kill() function.
• Signals in TNS processes and native processes
Any OSS process (native or G-series TNS) can use OSS signals functions. Only a Guardian
native process can use OSS signals functions.
• Interrupts from a terminal as signals
When a user presses an interrupt key at a terminal, an OSS process receives the interrupt as
a signal. A Guardian process receives the interrupt as a system message and must read its
$RECEIVE file to get the interrupt.
• Process signal mask
The process signal mask of an OSS process is initialized to that of its parent. The process
signal mask of a Guardian process is initialized so that no signals are blocked from delivery
to it.
• Default signal handler
The Common Run-Time Environment (CRE) sets up a default signal handler for a Guardian
program written in C. The CRE does not set up a default signal handler for an OSS program
written in C.
Using HP Signals Extension Functions
Guardian TNS processes receive traps to indicate run-time events requiring immediate attention.
Guardian native processes receive signals to indicate conditions known as traps in Guardian TNS
processes.
The HP signals extensions are provided as migration and convenience tools that allow native
processes to catch signals corresponding to trap conditions in TNS processes. The signals extensions
provide shortcuts to the same basic functions as provided by the standard signal interfaces.
Both OSS and Guardian native processes can use the signals extensions, but you probably won’t
have much reason to use them because you are concerned with handling the full range of signals,
not just those known as traps in Guardian TNS programs. Traps are a subset of all signals. Also,
the standard signals functions are portable and the HP extensions are not.
The signals extensions are available in C and pTAL. The C versions are SIGACTION_INIT_(),
SIGJMP_MASKSET_(), SIGACTION_SUPPLANT_(), and SIGACTION_RESTORE_().
118 Managing Processes