|
|
1.1 ! root 1: .\" Copyright (c) 1983 Regents of the University of California. ! 2: .\" All rights reserved. The Berkeley software License Agreement ! 3: .\" specifies the terms and conditions for redistribution. ! 4: .\" ! 5: .\" @(#)1.3.t 6.2 (Berkeley) 5/12/86 ! 6: .\" ! 7: .sh "Signals ! 8: .PP ! 9: .NH 3 ! 10: Overview ! 11: .PP ! 12: The system defines a set of \fIsignals\fP that may be delivered ! 13: to a process. Signal delivery resembles the occurrence of a hardware ! 14: interrupt: the signal is blocked from further occurrence, ! 15: the current process context is saved, and a new one ! 16: is built. A process may specify ! 17: the \fIhandler\fP to which a signal is delivered, or specify that ! 18: the signal is to be \fIblocked\fP or \fIignored\fP. A process may ! 19: also specify that a ! 20: \fIdefault\fP action is to be taken when signals occur. ! 21: .PP ! 22: Some signals ! 23: will cause a process to exit when they are not caught. This ! 24: may be accompanied by creation of a \fIcore\fP image file, containing ! 25: the current memory image of the process for use in post-mortem debugging. ! 26: A process may choose to have signals delivered on a special ! 27: stack, so that sophisticated software stack manipulations are possible. ! 28: .PP ! 29: All signals have the same \fIpriority\fP. If multiple signals ! 30: are pending simultaneously, the order in which they are delivered ! 31: to a process is implementation specific. Signal routines execute ! 32: with the signal that caused their invocation \fIblocked\fP, but other ! 33: signals may yet occur. Mechanisms are provided whereby critical sections ! 34: of code may protect themselves against the occurrence of specified signals. ! 35: .NH 3 ! 36: Signal types ! 37: .PP ! 38: The signals defined by the system fall into one of ! 39: five classes: hardware conditions, ! 40: software conditions, input/output notification, process control, or ! 41: resource control. ! 42: The set of signals is defined in the file \fI<signal.h>\fP. ! 43: .PP ! 44: Hardware signals are derived from exceptional conditions which ! 45: may occur during ! 46: execution. Such signals include SIGFPE representing floating ! 47: point and other arithmetic exceptions, SIGILL for illegal instruction ! 48: execution, SIGSEGV for addresses outside the currently assigned ! 49: area of memory, and SIGBUS for accesses that violate memory ! 50: protection constraints. ! 51: Other, more cpu-specific hardware signals exist, ! 52: such as those for the various customer-reserved instructions on ! 53: the VAX (SIGIOT, SIGEMT, and SIGTRAP). ! 54: .PP ! 55: Software signals reflect interrupts generated by user request: ! 56: SIGINT for the normal interrupt signal; SIGQUIT for the more ! 57: powerful \fIquit\fP signal, that normally causes a core image ! 58: to be generated; SIGHUP and SIGTERM that cause graceful ! 59: process termination, either because a user has ``hung up'', or ! 60: by user or program request; and SIGKILL, a more powerful termination ! 61: signal which a process cannot catch or ignore. ! 62: Programs may define their own asynchronous events using SIGUSR1 ! 63: and SIGUSR2. ! 64: Other software signals (SIGALRM, SIGVTALRM, SIGPROF) ! 65: indicate the expiration of interval timers. ! 66: .PP ! 67: A process can request notification via a SIGIO signal ! 68: when input or output is possible ! 69: on a descriptor, or when a \fInon-blocking\fP operation completes. ! 70: A process may request to receive a SIGURG signal when an ! 71: urgent condition arises. ! 72: .PP ! 73: A process may be \fIstopped\fP by a signal sent to it or the members ! 74: of its process group. The SIGSTOP signal is a powerful stop ! 75: signal, because it cannot be caught. Other stop signals ! 76: SIGTSTP, SIGTTIN, and SIGTTOU are used when a user request, input ! 77: request, or output request respectively is the reason for stopping the process. ! 78: A SIGCONT signal is sent to a process when it is ! 79: continued from a stopped state. ! 80: Processes may receive notification with a SIGCHLD signal when ! 81: a child process changes state, either by stopping or by terminating. ! 82: .PP ! 83: Exceeding resource limits may cause signals to be generated. ! 84: SIGXCPU occurs when a process nears its CPU time limit and SIGXFSZ ! 85: warns that the limit on file size creation has been reached. ! 86: .NH 3 ! 87: Signal handlers ! 88: .PP ! 89: A process has a handler associated with each signal. ! 90: The handler controls the way the signal is delivered. ! 91: The call ! 92: .DS ! 93: #include <signal.h> ! 94: ! 95: ._f ! 96: struct sigvec { ! 97: int (*sv_handler)(); ! 98: int sv_mask; ! 99: int sv_flags; ! 100: }; ! 101: ! 102: sigvec(signo, sv, osv) ! 103: int signo; struct sigvec *sv; result struct sigvec *osv; ! 104: .DE ! 105: assigns interrupt handler address \fIsv_handler\fP to signal \fIsigno\fP. ! 106: Each handler address ! 107: specifies either an interrupt routine for the signal, that the ! 108: signal is to be ignored, ! 109: or that a default action (usually process termination) is to occur ! 110: if the signal occurs. ! 111: The constants ! 112: SIG_IGN and SIG_DEF used as values for \fIsv_handler\fP ! 113: cause ignoring or defaulting of a condition. ! 114: The \fIsv_mask\fP value specifies the ! 115: signal mask to be used when the handler is invoked; it implicitly includes ! 116: the signal which invoked the handler. ! 117: Signal masks include one bit for each signal; ! 118: the mask for a signal \fIsigno\fP is provided by the macro ! 119: \fIsigmask\fP(\fIsigno\fP), from \fI<signal.h>\fP. ! 120: \fISv_flags\fP specifies whether system calls should be ! 121: restarted if the signal handler returns and ! 122: whether the handler should operate on the normal run-time ! 123: stack or a special signal stack (see below). If \fIosv\fP ! 124: is non-zero, the previous signal vector is returned. ! 125: .PP ! 126: When a signal condition arises for a process, the signal ! 127: is added to a set of signals pending for the process. ! 128: If the signal is not currently \fIblocked\fP by the process ! 129: then it will be delivered. The process of signal delivery ! 130: adds the signal to be delivered and those signals ! 131: specified in the associated signal ! 132: handler's \fIsv_mask\fP to a set of those \fImasked\fP ! 133: for the process, saves the current process context, ! 134: and places the process in the context of the signal ! 135: handling routine. The call is arranged so that if the signal ! 136: handling routine exits normally the signal mask will be restored ! 137: and the process will resume execution in the original context. ! 138: If the process wishes to resume in a different context, then ! 139: it must arrange to restore the signal mask itself. ! 140: .PP ! 141: The mask of \fIblocked\fP signals is independent of handlers for ! 142: signals. It delays signals from being delivered much as a ! 143: raised hardware interrupt priority level delays hardware interrupts. ! 144: Preventing an interrupt from occurring by changing the handler is analogous to ! 145: disabling a device from further interrupts. ! 146: .PP ! 147: The signal handling routine \fIsv_handler\fP is called by a C call ! 148: of the form ! 149: .DS ! 150: (*sv_handler)(signo, code, scp); ! 151: int signo; long code; struct sigcontext *scp; ! 152: .DE ! 153: The \fIsigno\fP gives the number of the signal that occurred, and ! 154: the \fIcode\fP, a word of information supplied by the hardware. ! 155: The \fIscp\fP parameter is a pointer to a machine-dependent ! 156: structure containing the information for restoring the ! 157: context before the signal. ! 158: .NH 3 ! 159: Sending signals ! 160: .PP ! 161: A process can send a signal to another process or group of processes ! 162: with the calls: ! 163: .DS ! 164: kill(pid, signo) ! 165: int pid, signo; ! 166: ! 167: killpgrp(pgrp, signo) ! 168: int pgrp, signo; ! 169: .DE ! 170: Unless the process sending the signal is privileged, ! 171: it must have the same effective user id as the process receiving the signal. ! 172: .PP ! 173: Signals are also sent implicitly from a terminal device to the ! 174: process group associated with the terminal when certain input characters ! 175: are typed. ! 176: .NH 3 ! 177: Protecting critical sections ! 178: .PP ! 179: To block a section of code against one or more signals, a \fIsigblock\fP ! 180: call may be used to add a set of signals to the existing mask, returning ! 181: the old mask: ! 182: .DS ! 183: oldmask = sigblock(mask); ! 184: result long oldmask; long mask; ! 185: .DE ! 186: The old mask can then be restored later with \fIsigsetmask\fP\|, ! 187: .DS ! 188: oldmask = sigsetmask(mask); ! 189: result long oldmask; long mask; ! 190: .DE ! 191: The \fIsigblock\fP call can be used to read the current mask ! 192: by specifying an empty \fImask\fP\|. ! 193: .PP ! 194: It is possible to check conditions with some signals blocked, ! 195: and then to pause waiting for a signal and restoring the mask, by using: ! 196: .DS ! 197: sigpause(mask); ! 198: long mask; ! 199: .DE ! 200: .NH 3 ! 201: Signal stacks ! 202: .PP ! 203: Applications that maintain complex or fixed size stacks can use ! 204: the call ! 205: .DS ! 206: ._f ! 207: struct sigstack { ! 208: caddr_t ss_sp; ! 209: int ss_onstack; ! 210: }; ! 211: ! 212: sigstack(ss, oss) ! 213: struct sigstack *ss; result struct sigstack *oss; ! 214: .DE ! 215: to provide the system with a stack based at \fIss_sp\fP for delivery ! 216: of signals. The value \fIss_onstack\fP indicates whether the ! 217: process is currently on the signal stack, ! 218: a notion maintained in software by the system. ! 219: .PP ! 220: When a signal is to be delivered, the system checks whether ! 221: the process is on a signal stack. If not, then the process is switched ! 222: to the signal stack for delivery, with the return from the signal ! 223: arranged to restore the previous stack. ! 224: .PP ! 225: If the process wishes to take a non-local exit from the signal routine, ! 226: or run code from the signal stack that uses a different stack, ! 227: a \fIsigstack\fP call should be used to reset the signal stack.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.