FTAM/9000 Programmer's Guide

Chapter 4 185
Using Support Functions
Responding to Asynchronous Calls
Handling Signal Interrupts
Suppose an application needs the em_wait() function to return
prematurely if a signal interrupt occurs. One case where this is
applicable is when receipt of a signal should cause a new FTAM
operation to be initiated or an outstanding operation to be aborted (e.g.,
the application is being terminated abruptly). Since FTAM functions are
not reentrant, the application needs to force em_wait() to return
prematurely so the appropriate action can be taken upon receipt of the
signal.
The em_wait() and em_hp_select() functions cannot detect signal
interrupts and automatically return. However, you can cause
em_hp_select() to return when interrupted by a signal. This involves
translating the signal interrupt into an em_hp_select() non-FTAM event
while executing the signal handler. When em_hp_select() resumes
processing after the signal handler completes, the non-FTAM event will
be detected and em_hp_select() will return.
Several techniques exist to translate the signal interrupt into an
em_hp_select() non-FTAM event. One way is to use an HP–UX pipe as
follows:
1. Open the pipe for both reading and writing within the application
program.
2. For the expected signals, install a signal handler that writes the
trapped signal value to the pipe. This will cause the pipe to become
readable.
3. Replace calls to em_wait() (which waits for only FTAM events) with
calls to em_hp_select(). Initialize the readfds mask to include the read
descriptor for the pipe. If a signal interrupt occurs while executing or
blocking within em_hp_select(), the pipe will become readable and
cause em_hp_select() to return.
4. After em_hp_select() returns, read the signal value from the pipe so
that the notification will be cleared; then take the appropriate action
based on the signal value.