HP-UX Reference (11i v1 05/09) - 2 System Calls (vol 5)

s
sigvector(2) sigvector(2)
(TO BE OBSOLETED)
SV_BSDSIG
Use the Berkeley signal semantics.
SV_RESETHAND Use the semantics of signal(2).
If SV_ONSTACK is set, the system uses or permits the use of the space reserved for signal processing in
the sigspace() system call.
If SV_BSDSIG is set, the signal is given the Berkeley semantics. The following signal is affected by this
flag:
SIGCLD In addition to being sent when a child process dies, the signal is also sent when any
child’s status changes from running to stopped. This would normally be used by a pro-
gram such as csh (see csh(1)) when maintaining process groups under Berkeley job
control.
If SV_RESETHAND is set, the signal handler is installed with the same semantics as a handler installed
with signal(2). This affects signal mask set-up during the signal handler (see above) and whether the
handler is reset after a signal is caught (see below).
If SV_RESETHAND is not set, once a signal handler is installed, it remains installed until another
sigvector() call is made or an exec()
system call is performed (see exec(2)). If SV_RESETHAND is
set and the signal is not one of those marked "not reset when caught" under signal(5), the default action is
reinstated when the signal is caught, prior to entering the signal-catching function. The "not reset when
caught" distinction is not significant when
sigvector() is called and SV_RESETHAND is not set.
The default action for a signal can be reinstated by setting sv_handler to SIG_DFL; this default usually
results in termination of the process. If sv_handler is
SIG_IGN the signal is usually subsequently
ignored, and pending instances of the signal are discarded. The exact meaning of SIG_DFL and
SIG_IGN for each signal is discussed in signal(5).
Certain system calls can be interrupted by a signal; all other system calls complete before the signal is ser-
viced. The scp pointer described in signal(5) is never null if sigvector() is supported. scp points to a
machine-dependent sigcontext structure. All implementations of this structure include the fields:
int sc_syscall;
char sc_syscall_action;
The value
SYS_NOTSYSCALL
for the sc_syscall field indicates that the signal is not interrupting a system
call; any other value indicates which system call it is interrupting.
If a signal that is being caught occurs during a system call that can be interrupted, the signal handler is
immediately invoked. If the signal handler exits normally, the value of the sc_syscall_action field is
inspected; if the value is
SIG_RETURN , the system call is aborted and the interrupted program continues
past the call. The result of the interrupted call is −1 and errno is set to
EINTR. If the value of the
sc_syscall_action field is
SIG_RESTART , the call is restarted. A call is restarted if, in the case of a
read() or write() system call (see read(2) or write(2)), it had transferred no data. If some data had
been transferred, the operation is considered to have completed with a partial transfer, and the sc_syscall
value is
SYS_NOTSYSCALL
. Other values are undefined and reserved for future use.
Exiting the handler abnormally (such as with
longjmp() — see setjmp(3C)) aborts the call, leaving the
user responsible for the context of further execution. The value of scp−>sc_syscall_action is ignored when
the value of scp−>sc_syscall is
SYS_NOTSYSCALL
. scp−>sc_syscall_action is always initialized to
SIG_RETURN before invocation of a signal handler. When an system call that can be interrupted is inter-
rupted by multiple signals, if any signal handler returns a value of SIG_RETURN in
scp−>sc_syscall_action, all subsequent signal handlers are passed a value of SYS_NOTSYSCALL
in
scp−>sc_syscall.
Note that calls to
read(), write(),orioctl() on fast devices (such as disks) cannot be interrupted,
but I/O to a slow device (such as a printer) can be interrupted. Other system calls, such as those used for
networking, also can be interrupted on some implementations. In these cases additional values can be
specified for scp−>sc_syscall. Programs that look at the values of scp−>sc_syscall always should compare
them to these symbolic constants; the numerical values represented by these constants might vary among
implementations. System calls that can be interrupted and their corresponding values for scp−>sc_syscall
are listed below:
Section 2−−392 Hewlett-Packard Company − 2 − HP-UX 11i Version 1: September 2005