Signal-Handling Functions

Using Signals Reliably

The key to writing programs that handle signals reliably is to keep close control of when signals can occur. In particular, you can simplify program logic if you avoid handling signals while main-line code is testing or modifying variables that are also accessed or modified by a signal handler.

Some of the ways you can use the library facilities to control when signals must be handled are discussed here. Note that these techniques, with the exception of the first one, are specific to the SAS/C library.

Code carefully to avoid generating computational signals, such as division by 0, or memory access violations. Because these signals cannot be delayed, the only way to keep them from occurring at an inconvenient time is to write code that does not cause them. Sometimes the input data make it impossible to avoid generating signals. In such situations, be aware that the signals can occur and be prepared to handle them.
The library discovers asynchronous signals only when a function is called or returns. Therefore, manipulation of critical data is not interrupted by an asynchronous signal if you do not call any functions.
If you must call a function to manipulate data tested or modified by a signal handler, call sigprocmask or sigblock before calling the function to minimize the chance of being interrupted. Then call sigprocmask or sigsetmask to restore the signal mask when the critical activity is completed. The call to sigprocmask or sigblock allows any pending signals to be discovered, so interruption is possible at this point. However, if no signals are pending, no other interruptions occur until you reset the mask with sigprocmask or sigsetmask .
If you want to reinstate signal handling within a handler, delay calling signal in the handler for as long as possible. The library postpones processing new asynchronous signals while a handler is executing, unless the handler calls sigchk or signal . As soon as you call signal , any pending signals are discovered and handled. Alternately, use sigaction rather than signal to define your handlers. In this case, you do not need to call signal again to reinstate your handler, and you can have any signals you wish blocked automatically during the handler's execution.
To ensure that interrupt-driven programs handle signals one at a time, use sigprocmask to block signals until the program is ready to process interruptions. When an interruption can be processed, call sigsuspend to wait for the next signal. When the signal occurs, the library automatically restores the pre- sigsuspend signal mask before calling your handler.
Because the SAS/C library discovers signals only when you call a function or when it returns, you may need to add calls to sigchk to discover signals at points in your code that do not call any functions. Be sure to select points at which all data structures used by handlers are in a consistent state.
If you have handlers that call the longjmp function, you may want to use the blkjmp function in routines that can be interrupted to protect some portions of the routine. This permits the routine to successfully complete activities that should not be interrupted. Note that if a handler calls longjmp while I/O is being performed, the error flag is set for the file. You must call clearerr to continue to use the file, but be aware that information may be lost from the file.
Unless you block it, the SIGINT signal (as well as USS signals such as SIGTTIN ) can occur at any time while the program is waiting for input from the terminal.

Chapter Contents
Previous
Next
Top of Page