Chapter Contents

Signal-Handling Functions

Discovering Asynchronous Signals

As mentioned earlier, the library calls handlers for synchronous signals as soon as the signal occurs; however, when an asynchronous signal occurs, the library may not immediately call the handler. There may be a delay because the signal must be discovered by the run-time library. After the signal is discovered, the library calls the handler. There are only three times asynchronous signals are discovered:

when a function is called
when a function returns
when the special function sigchk is called to discover pending asynchronous signals.

You can insert calls to sigchk in your program to decrease the number of statements that are executed before a signal is discovered.

The library limits the times that an asynchronous signal can be discovered to improve your control of signal handling. There are two reasons the SAS/C library delays processing asynchronous signals:

If the library allowed the operating system to call signal handlers as soon as a signal occurred, the signal handler would not be able to use facilities such as exit and longjmp . Using these facilities bypasses return to the operating system, which causes unpredictable results. By limiting signal discovery (and signal handling) to times when the library has control, the library permits you to use all of the facilities of C, including longjmp and exit . (For some signals under CMS, I/O also would not be available to handlers if they were called immediately.)
Program reliability is improved by restricting the circumstances under which handlers can be called. For example, suppose your program adds elements to an array and contains the following code:
```
++elements;
table[elements] = value;
```
If a signal handler were called between these two statements, an attempt by a handler to add an element to the table would cause an entry to be skipped. Knowing that signals are not discovered at this point, you do not need to worry about skipped entries.
Note: Combining the two statements into one does not improve the situation because signals can occur between any two machine instructions whether or not they are part of the same statement.

This method of discovering asynchronous signals is a feature of the SAS/C implementation. If you are writing portable code be aware that, on some systems, handlers are always called immediately. In such systems, you must write code carefully to avoid incorrect results if signals are inconveniently timed.

Delaying Discovery of Signals

For many applications, coding a signal handler is complicated by the possibility that a new signal may be generated during the handler's execution (either the same signal or a completely unrelated signal). For POSIX applications, the sigaction function makes it easy to block signals during the execution of a signal handler. For non-POSIX applications, the situation is more complicated, and it may be difficult to block asynchronous signals during the execution of a signal handler. To assist in the writing of reliable code, the SAS/C library suppresses the discovery of new asynchronous signals within a handler. An exception is when the handler calls sigchk , signal , or sigaction , which indicates its readiness to handle new signals. This applies only to asynchronous signals; for example, if a handler divides by 0, the resulting signal cannot be delayed no matter how convenient that might be. Also, any signals that are pending while a handler executes are discovered and processed when the handler returns.

If you are writing portable code be aware that, on some systems, asynchronous signals are discovered even while a handler is executing. On such systems, you must write code carefully to avoid incorrect results if signals are inconveniently timed.

Waiting for Signals

Some programs are interrupt driven; that is, their operation is controlled by signals from external sources (for example, IUCV signals from other VM users). For such programs, it is important to have a waiting period without using CPU resources until a signal is received. The library provides the following functions for this purpose:

pause , sigpause , and sigsuspend suspend execution until a signal is received
ecbpause and ecbsuspend wait for either a signal or for an Event Control Block (ECB) to be posted
sleep and sleepd suspend execution until a signal is received or an elapsed time interval expires. If a signal is received while program execution is suspended by one of these functions, the signal is handled immediately, unless the signal is blocked.

Chapter Contents
Previous
Next
Top of Page

Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.