Chapter Contents |
Previous |
Next |
Coprocessing Functions |
Signal handling for programs that use coprocesses is
complex because program requirements differ depending on the situation and
the signals involved. For instance, for computational signals such as
SIGFPE
, you may prefer a separate
signal handler for each coprocess. On the other hand, for a signal such as
SIGINT
that can occur at any
time, independent of coprocess switches, you may prefer a single handler,
which is called regardless of the coprocess active at the time of the signal.
The coprocess implementation enables you to define local and global handlers
for each signal independently in whatever way is most convenient for your
application.
In addition, the library maintains a separate signal-blocking
mask for each coprocess. This allows coprocesses to block signals that they
are not equipped to handle, while assuring that signals are recognized whenever
an appropriate coprocess becomes active. By default, all coprocesses except
the main coprocess are created with all signals blocked. For this reason,
unless a new coprocess issues
sigsetmask
or
sigprocmask
, no asynchronous signals are detected during its execution. Therefore,
you can write subroutines that create coprocesses, and you do not need any
special code to avoid interference with the asynchronous signal handling of
the rest of the program. Note that you can use the second argument to
costart
to specify a different
signal mask for the new coprocess.
When you use coprocesses, there are two functions available
to define signal handlers:
signal
and
cosignal
.
signal
defines a local
handler, a function that is called only for signals discovered while
the coprocess that defined the handler is active.
cosignal
defines a global handler, a function that is
called for signals discovered during the execution of any coprocess. If,
at the time of signal discovery, both a local and global handler are defined,
the local handler is called unless the local handler is
SIG_DFL
, in which case the global handler is
called.
Usually, you want to define local handlers (using the
signal
function) for synchronous
signals and global handlers (using the
cosignal
function) for asynchronous signals. For instance, a
SIGFPE
handler normally is defined
with
signal
because
SIGFPE
cannot occur while a coprocess
is active except as the result of code executed by that coprocess. On the
other hand, a
SIGINT
handler
normally is defined with
cosignal
because the time at which a
SIGINT
signal is generated has no relationship to coprocess activity.
The local and global signal handlers are maintained
independently. A call to
signal
returns the previous local handler for the calling coprocess; a call
to
cosignal
returns the
previous global handler.
You can also use
sigaction
to establish local or global handlers. Ordinarily,
sigaction
defines a local handler.
You can set the
sa_flags
bit
SA_GLOBAL
to define
a global handler instead.
Note that when a signal handler is called, no coprocess
switch takes place; the handler executes as part of the interrupted coprocess.
If you want a signal to be handled by a particular coprocess, you either
can have all other coprocesses block the signal or you can define a global
handler that cocalls the relevant coprocess, if that coprocess was not the
one interrupted. An example of the latter technique is shown in the
cosignal
function description.
Note that global handlers generally should not use
longjmp
unless they first verify
that the active coprocess is the one that issued the corresponding call to
setjmp
.
Chapter Contents |
Previous |
Next |
Top of Page |
Copyright © 2001 by SAS Institute Inc., Cary, NC, USA. All rights reserved.