![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 1.3.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman|
Return to 1.3.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman |
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.