NAME

sigvector − software signal facilities

SYNOPSIS

#include <signal.h>

sigvector(sig, vec, ovec)
int sig;
struct sigvec *vec, *ovec;

HP-UX COMPATIBILITY

Level: HP-UX/STANDARD

Origin: UCB and HP

DESCRIPTION

The system defines a set of signals that may be delivered to a process.  The set of signals is defined in signal(2), along with the meaning and side effects of each signal. This manual page, along with those for sigblock(2), sigsetmask(2), sigpause(2), and sigspace(2) define an alternate mechanism for handling these signals that assures the delivery of signals and integrity of signal handling procedures. The facilities described here should not be used in the same program as signal(2) without a thorough understanding of the interactions between the two mechanisms.

With this interface, signal delivery resembles the occurrence of a hardware interrupt: the signal is blocked from further occurrence, the current process context is saved, and a new one is built.  A process may specify a handler to which a signal is delivered, or specify that a signal is to be blocked or ignored. A process may also specify that a default action is to be taken by the system when a signal occurs. It is possible to assure a minimum amount of stack space for processing signals using the sigspace(2) call.

All signals have the same priority.  Signal routines execute with the signal that caused their invocation blocked, but other signals may yet occur. A global signal mask defines the set of signals currently blocked from delivery to a process.  The signal mask for a process is initialized from that of its parent (normally 0).  It may be changed with a sigblock(2), sigsetmask(2), or sigpause(2) call, or when a signal is delivered to the process.

When a signal condition arises for a process, the signal is added to a set of signals pending for the process.  If the signal is not currently blocked by the process then it is delivered to the process.  When a signal is delivered, the current state of the process is saved, a new signal mask is calculated (as described below), and the signal handler is invoked.  The call to the handler is arranged so that if the signal handling routine returns normally the process will resume execution in the context from before the signal’s delivery.  If the process wishes to resume in a different context, then it must arrange to restore the previous context itself. 

When a signal is delivered to a process a new signal mask is installed for the duration of the process’ signal handler (or until a sigblock or sigsetmask call is made).  This mask is formed by taking the current signal mask, adding the signal to be delivered, and or’ing in the signal mask associated with the handler to be invoked. When the user’s signal handler returns normally, the original mask is restored.

Sigvector assigns a handler for a specific signal.  Vec and ovec are pointers to sigvec structures which include the following elements:

 int(*sv_handler)();
intsv_mask;
intsv_onstack;
 

If vec is non-zero, it specifies a handler routine and mask to be used when delivering the specified signal.  Further, if sv_onstack is 1, the system will use, or permit the use of, the space reserved for signal processing in the sigspace(2) call. If ovec is non-zero, the previous handling information for the signal is returned to the user.  If vec is zero, signal handling is unchanged; thus, the call can be used to enquire about the current handling of a given signal. 

Once a signal handler is installed, it remains installed until another sigvector call is made, or an exec(2) is performed. The default action for a signal may be reinstated by setting sv_handler to SIG_DFL; this default is usually termination.  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(2). Unlike signal(2) there is no category of "reset when caught" signals.

Certain system calls can be interrupted by a signal, the remainder will complete before the signal is serviced.  The scp pointer described in signal(2) is always non-null if sigvector is supported.  Scp points to a machine-dependent sigcontext structure.  All implementations of this structure include the field

     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 which is being caught occurs during one of the interruptable calls, the signal handler is immediately invoked.  If the signal handler is exited in a normal way, 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 with the result of the interrupted call being -1 and errno set to EINTR.  If the value of the sc_syscall_action field is SIG_RESTART, the call is restarted.  Other values are undefined and reserved for future use. 

Exiting the handler abnormally (such as with longjmp(3)) will abort the call, and the user is responsible for the context of further execution. The value of scp->sc_syscall is ignored when the value of scp->sc_syscall is SYS_NOTSYSCALL. 

When a signal interrupts a read, write, readv, or writev call that has transferred a non-zero portion of the requested data, the call is considered to have completed with a partial transfer.  In this case, the signal handler is invoked with scp->sc_syscall set to SYS_NOT_SYSCALL and, following return from the handler, the system call returns the number of bytes actually transferred. 

When an interruptable call is interrupted 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.  scp->sc_syscall_action is always initialized to SIG_RETURN before invocation of a signal handler. 

The interruptable system calls, and corresponding values for scp->sc_syscall are listed below. 

Callsc_syscall value
--------------------
readSYS_READ
  (slow devices)
readvSYS_READV
  (slow devices)
writeSYS_WRITE
  (slow devices)
writevSYS_WRITEV
  (slow devices)
openSYS_OPEN
  (slow devices)
ioctlSYS_IOCTL
  (slow requests)
waitSYS_WAIT
selectSYS_SELECT
pauseSYS_PAUSE
sigpauseSYS_SIGPAUSE
semopSYS_SEMOP
msgsndSYS_MSGSND
msgrcvSYS_MSGRCV

Note that read, readv, write, writev, open, or ioctl on fast devices (discs) is not interruptable, but I/O to a slow device (terminal) is.  Additional system calls such as those used for networking may also be interruptable on some implementations.  In these cases, additional values may be specified for scp->sc_syscall.  Programs that look at the values of scp->sc_syscall should always compare them to these symbolic constants; the numerical values represented by these constants vary among implementations. 

After a fork(2) or vfork(2) the child inherits all signals, the signal mask, and the reserved signal stack space.

Exec(2) resets all caught signals to default action; ignored signals remain ignored; the signal mask remains the same; the reserved signal stack space is released.

NOTES

The mask specified in vec is not allowed to block those signals which cannot be ignored, as defined in signal(2). This is enforced silently by the system.

If sigvector is called to catch SIGCLD in a process which has currently terminated (zombie) children, a SIGCLD signal is delivered to the calling process immediately, or as soon as SIGCLD is unblocked if it is currently blocked.  Thus, in a process which spawns multiple children and catches SIGCLD, it is somtimes advisable to re-install the handler for SIGCLD after each invocation in case there are multiple zombies present.  This is true even though the handling of the signal is not reset by the system as with signal(2); otherwise, the presence of the zombie which caused the first signal will always cause another signal to be sent.

RETURN VALUE

A 0 value indicated that the call succeeded.  A −1 return value indicates an error occurred and errno is set to indicate the reason. 

ERRORS

Sigvector will fail and no new signal handler will be installed if one of the following occurs:

[EFAULT] Either vec or ovec points to memory which is not a valid part of the process address space. 

[EINVAL] Sig is not a valid signal number. 

[EINVAL] An attempt is made to ignore or supply a handler for a signal which cannot be caught or ignored.  See signal (2). 

SEE ALSO

kill(1), ptrace(2), kill(2), sigblock(2), sigsetmask(2), sigpause(2), sigspace(2), setjmp(3), signal(2), termio(4)

WARNING

Restarting a select(2) call can sometimes cause unexpected results. If the select call has a timeout specified, the timeout is restarted with the call, ignoring any portion which had elapsed prior to interruption by the signal. Normally this simply extends the timeout and is not a problem. However, if a handler repeatedly catches signals and the timeout specified to select is longer than the time between those signals, restarting the select call effectively renders the timeout infinite.
 
 

Hewlett-Packard  —  last mod. May 11, 2021