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:
sigchkis called to discover pending asynchronous signals.
insert calls to
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:
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
exit. (For some signals under CMS, I/O also would not be available to handlers if they were called immediately.)
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.
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
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
, 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:
sigsuspendsuspend execution until a signal is received
ecbsuspendwait for either a signal or for an Event Control Block (ECB) to be posted
sleepdsuspend 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.
Top of Page
Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.