Update from main archive 961219
[kopensolaris-gnu/glibc.git] / manual / signal.texi
1 @node Signal Handling, Process Startup, Non-Local Exits, Top
2 @chapter Signal Handling
3
4 @cindex signal
5 A @dfn{signal} is a software interrupt delivered to a process.  The
6 operating system uses signals to report exceptional situations to an
7 executing program.  Some signals report errors such as references to
8 invalid memory addresses; others report asynchronous events, such as
9 disconnection of a phone line.
10
11 The GNU C library defines a variety of signal types, each for a
12 particular kind of event.  Some kinds of events make it inadvisable or
13 impossible for the program to proceed as usual, and the corresponding
14 signals normally abort the program.  Other kinds of signals that report
15 harmless events are ignored by default.
16
17 If you anticipate an event that causes signals, you can define a handler
18 function and tell the operating system to run it when that particular
19 type of signal arrives.
20
21 Finally, one process can send a signal to another process; this allows a
22 parent process to abort a child, or two related processes to communicate
23 and synchronize.
24
25 @menu
26 * Concepts of Signals::         Introduction to the signal facilities.
27 * Standard Signals::            Particular kinds of signals with
28                                  standard names and meanings.
29 * Signal Actions::              Specifying what happens when a
30                                  particular signal is delivered.
31 * Defining Handlers::           How to write a signal handler function.
32 * Interrupted Primitives::      Signal handlers affect use of @code{open},
33                                  @code{read}, @code{write} and other functions.
34 * Generating Signals::          How to send a signal to a process.
35 * Blocking Signals::            Making the system hold signals temporarily.
36 * Waiting for a Signal::        Suspending your program until a signal
37                                  arrives.
38 * Signal Stack::                Using a Separate Signal Stack.
39 * BSD Signal Handling::         Additional functions for backward
40                                  compatibility with BSD.
41 @end menu
42
43 @node Concepts of Signals
44 @section Basic Concepts of Signals
45
46 This section explains basic concepts of how signals are generated, what
47 happens after a signal is delivered, and how programs can handle
48 signals.
49
50 @menu
51 * Kinds of Signals::            Some examples of what can cause a signal.
52 * Signal Generation::           Concepts of why and how signals occur.
53 * Delivery of Signal::          Concepts of what a signal does to the
54                                  process.
55 @end menu
56
57 @node Kinds of Signals
58 @subsection Some Kinds of Signals
59
60 A signal reports the occurrence of an exceptional event.  These are some
61 of the events that can cause (or @dfn{generate}, or @dfn{raise}) a
62 signal:
63
64 @itemize @bullet
65 @item
66 A program error such as dividing by zero or issuing an address outside
67 the valid range.
68
69 @item
70 A user request to interrupt or terminate the program.  Most environments
71 are set up to let a user suspend the program by typing @kbd{C-z}, or
72 terminate it with @kbd{C-c}.  Whatever key sequence is used, the
73 operating system sends the proper signal to interrupt the process.
74
75 @item
76 The termination of a child process.
77
78 @item
79 Expiration of a timer or alarm.
80
81 @item
82 A call to @code{kill} or @code{raise} by the same process.
83
84 @item
85 A call to @code{kill} from another process.  Signals are a limited but
86 useful form of interprocess communication.
87
88 @item
89 An attempt to perform an I/O operation that cannot be done.  Examples
90 are reading from a pipe that has no writer (@pxref{Pipes and FIFOs}),
91 and reading or writing to a terminal in certain situations (@pxref{Job
92 Control}).
93 @end itemize
94
95 Each of these kinds of events (excepting explicit calls to @code{kill}
96 and @code{raise}) generates its own particular kind of signal.  The
97 various kinds of signals are listed and described in detail in
98 @ref{Standard Signals}.
99
100 @node Signal Generation
101 @subsection Concepts of Signal Generation
102 @cindex generation of signals
103
104 In general, the events that generate signals fall into three major
105 categories: errors, external events, and explicit requests.
106
107 An error means that a program has done something invalid and cannot
108 continue execution.  But not all kinds of errors generate signals---in
109 fact, most do not.  For example, opening a nonexistent file is an error,
110 but it does not raise a signal; instead, @code{open} returns @code{-1}.
111 In general, errors that are necessarily associated with certain library
112 functions are reported by returning a value that indicates an error.
113 The errors which raise signals are those which can happen anywhere in
114 the program, not just in library calls.  These include division by zero
115 and invalid memory addresses.
116
117 An external event generally has to do with I/O or other processes.
118 These include the arrival of input, the expiration of a timer, and the
119 termination of a child process.
120
121 An explicit request means the use of a library function such as
122 @code{kill} whose purpose is specifically to generate a signal.
123
124 Signals may be generated @dfn{synchronously} or @dfn{asynchronously}.  A
125 synchronous signal pertains to a specific action in the program, and is
126 delivered (unless blocked) during that action.  Most errors generate
127 signals synchronously, and so do explicit requests by a process to
128 generate a signal for that same process.  On some machines, certain
129 kinds of hardware errors (usually floating-point exceptions) are not
130 reported completely synchronously, but may arrive a few instructions
131 later.
132
133 Asynchronous signals are generated by events outside the control of the
134 process that receives them.  These signals arrive at unpredictable times
135 during execution.  External events generate signals asynchronously, and
136 so do explicit requests that apply to some other process.
137
138 A given type of signal is either typically synchronous or typically
139 asynchronous.  For example, signals for errors are typically synchronous
140 because errors generate signals synchronously.  But any type of signal
141 can be generated synchronously or asynchronously with an explicit
142 request.
143
144 @node Delivery of Signal
145 @subsection How Signals Are Delivered
146 @cindex delivery of signals
147 @cindex pending signals
148 @cindex blocked signals
149
150 When a signal is generated, it becomes @dfn{pending}.  Normally it
151 remains pending for just a short period of time and then is
152 @dfn{delivered} to the process that was signaled.  However, if that kind
153 of signal is currently @dfn{blocked}, it may remain pending
154 indefinitely---until signals of that kind are @dfn{unblocked}.  Once
155 unblocked, it will be delivered immediately.  @xref{Blocking Signals}.
156
157 @cindex specified action (for a signal)
158 @cindex default action (for a signal)
159 @cindex signal action
160 @cindex catching signals
161 When the signal is delivered, whether right away or after a long delay,
162 the @dfn{specified action} for that signal is taken.  For certain
163 signals, such as @code{SIGKILL} and @code{SIGSTOP}, the action is fixed,
164 but for most signals, the program has a choice: ignore the signal,
165 specify a @dfn{handler function}, or accept the @dfn{default action} for
166 that kind of signal.  The program specifies its choice using functions
167 such as @code{signal} or @code{sigaction} (@pxref{Signal Actions}).  We
168 sometimes say that a handler @dfn{catches} the signal.  While the
169 handler is running, that particular signal is normally blocked.
170
171 If the specified action for a kind of signal is to ignore it, then any
172 such signal which is generated is discarded immediately.  This happens
173 even if the signal is also blocked at the time.  A signal discarded in
174 this way will never be delivered, not even if the program subsequently
175 specifies a different action for that kind of signal and then unblocks
176 it.
177
178 If a signal arrives which the program has neither handled nor ignored,
179 its @dfn{default action} takes place.  Each kind of signal has its own
180 default action, documented below (@pxref{Standard Signals}).  For most kinds
181 of signals, the default action is to terminate the process.  For certain
182 kinds of signals that represent ``harmless'' events, the default action
183 is to do nothing.
184
185 When a signal terminates a process, its parent process can determine the
186 cause of termination by examining the termination status code reported
187 by the @code{wait} or @code{waitpid} functions.  (This is discussed in
188 more detail in @ref{Process Completion}.)  The information it can get
189 includes the fact that termination was due to a signal, and the kind of
190 signal involved.  If a program you run from a shell is terminated by a
191 signal, the shell typically prints some kind of error message.
192
193 The signals that normally represent program errors have a special
194 property: when one of these signals terminates the process, it also
195 writes a @dfn{core dump file} which records the state of the process at
196 the time of termination.  You can examine the core dump with a debugger
197 to investigate what caused the error.
198
199 If you raise a ``program error'' signal by explicit request, and this
200 terminates the process, it makes a core dump file just as if the signal
201 had been due directly to an error.
202
203 @node Standard Signals
204 @section Standard Signals
205 @cindex signal names
206 @cindex names of signals
207
208 @pindex signal.h
209 @cindex signal number
210 This section lists the names for various standard kinds of signals and
211 describes what kind of event they mean.  Each signal name is a macro
212 which stands for a positive integer---the @dfn{signal number} for that
213 kind of signal.  Your programs should never make assumptions about the
214 numeric code for a particular kind of signal, but rather refer to them
215 always by the names defined here.  This is because the number for a
216 given kind of signal can vary from system to system, but the meanings of
217 the names are standardized and fairly uniform.
218
219 The signal names are defined in the header file @file{signal.h}.
220
221 @comment signal.h
222 @comment BSD
223 @deftypevr Macro int NSIG
224 The value of this symbolic constant is the total number of signals
225 defined.  Since the signal numbers are allocated consecutively,
226 @code{NSIG} is also one greater than the largest defined signal number.
227 @end deftypevr
228
229 @menu
230 * Program Error Signals::       Used to report serious program errors.
231 * Termination Signals::         Used to interrupt and/or terminate the
232                                  program.
233 * Alarm Signals::               Used to indicate expiration of timers.
234 * Asynchronous I/O Signals::    Used to indicate input is available.
235 * Job Control Signals::         Signals used to support job control.
236 * Operation Error Signals::     Used to report operational system errors.
237 * Miscellaneous Signals::       Miscellaneous Signals.
238 * Signal Messages::             Printing a message describing a signal.
239 @end menu
240
241 @node Program Error Signals
242 @subsection Program Error Signals
243 @cindex program error signals
244
245 The following signals are generated when a serious program error is
246 detected by the operating system or the computer itself.  In general,
247 all of these signals are indications that your program is seriously
248 broken in some way, and there's usually no way to continue the
249 computation which encountered the error.
250
251 Some programs handle program error signals in order to tidy up before
252 terminating; for example, programs that turn off echoing of terminal
253 input should handle program error signals in order to turn echoing back
254 on.  The handler should end by specifying the default action for the
255 signal that happened and then reraising it; this will cause the program
256 to terminate with that signal, as if it had not had a handler.
257 (@xref{Termination in Handler}.)
258
259 Termination is the sensible ultimate outcome from a program error in
260 most programs.  However, programming systems such as Lisp that can load
261 compiled user programs might need to keep executing even if a user
262 program incurs an error.  These programs have handlers which use
263 @code{longjmp} to return control to the command level.
264
265 The default action for all of these signals is to cause the process to
266 terminate.  If you block or ignore these signals or establish handlers
267 for them that return normally, your program will probably break horribly
268 when such signals happen, unless they are generated by @code{raise} or
269 @code{kill} instead of a real error.
270
271 @vindex COREFILE
272 When one of these program error signals terminates a process, it also
273 writes a @dfn{core dump file} which records the state of the process at
274 the time of termination.  The core dump file is named @file{core} and is
275 written in whichever directory is current in the process at the time.
276 (On the GNU system, you can specify the file name for core dumps with
277 the environment variable @code{COREFILE}.)  The purpose of core dump
278 files is so that you can examine them with a debugger to investigate
279 what caused the error.
280
281 @comment signal.h
282 @comment ISO
283 @deftypevr Macro int SIGFPE
284 The @code{SIGFPE} signal reports a fatal arithmetic error.  Although the
285 name is derived from ``floating-point exception'', this signal actually
286 covers all arithmetic errors, including division by zero and overflow.
287 If a program stores integer data in a location which is then used in a
288 floating-point operation, this often causes an ``invalid operation''
289 exception, because the processor cannot recognize the data as a
290 floating-point number.
291 @cindex exception
292 @cindex floating-point exception
293
294 Actual floating-point exceptions are a complicated subject because there
295 are many types of exceptions with subtly different meanings, and the
296 @code{SIGFPE} signal doesn't distinguish between them.  The @cite{IEEE
297 Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985
298 and ANSI/IEEE Std 854-1987)}
299 defines various floating-point exceptions and requires conforming
300 computer systems to report their occurrences.  However, this standard
301 does not specify how the exceptions are reported, or what kinds of
302 handling and control the operating system can offer to the programmer.
303 @end deftypevr
304
305 BSD systems provide the @code{SIGFPE} handler with an extra argument
306 that distinguishes various causes of the exception.  In order to access
307 this argument, you must define the handler to accept two arguments,
308 which means you must cast it to a one-argument function type in order to
309 establish the handler.  The GNU library does provide this extra
310 argument, but the value is meaningful only on operating systems that
311 provide the information (BSD systems and GNU systems).
312
313 @table @code
314 @comment signal.h
315 @comment BSD
316 @item FPE_INTOVF_TRAP
317 @vindex FPE_INTOVF_TRAP
318 Integer overflow (impossible in a C program unless you enable overflow
319 trapping in a hardware-specific fashion).
320 @comment signal.h
321 @comment BSD
322 @item FPE_INTDIV_TRAP
323 @vindex FPE_INTDIV_TRAP
324 Integer division by zero.
325 @comment signal.h
326 @comment BSD
327 @item FPE_SUBRNG_TRAP
328 @vindex FPE_SUBRNG_TRAP
329 Subscript-range (something that C programs never check for).
330 @comment signal.h
331 @comment BSD
332 @item FPE_FLTOVF_TRAP
333 @vindex FPE_FLTOVF_TRAP
334 Floating overflow trap.
335 @comment signal.h
336 @comment BSD
337 @item FPE_FLTDIV_TRAP
338 @vindex FPE_FLTDIV_TRAP
339 Floating/decimal division by zero.
340 @comment signal.h
341 @comment BSD
342 @item FPE_FLTUND_TRAP
343 @vindex FPE_FLTUND_TRAP
344 Floating underflow trap.  (Trapping on floating underflow is not
345 normally enabled.)
346 @comment signal.h
347 @comment BSD
348 @item FPE_DECOVF_TRAP
349 @vindex FPE_DECOVF_TRAP
350 Decimal overflow trap.  (Only a few machines have decimal arithmetic and
351 C never uses it.)
352 @ignore @c These seem redundant
353 @comment signal.h
354 @comment BSD
355 @item FPE_FLTOVF_FAULT
356 @vindex FPE_FLTOVF_FAULT
357 Floating overflow fault.
358 @comment signal.h
359 @comment BSD
360 @item FPE_FLTDIV_FAULT
361 @vindex FPE_FLTDIV_FAULT
362 Floating divide by zero fault.
363 @comment signal.h
364 @comment BSD
365 @item FPE_FLTUND_FAULT
366 @vindex FPE_FLTUND_FAULT
367 Floating underflow fault.
368 @end ignore
369 @end table
370
371 @comment signal.h
372 @comment ISO
373 @deftypevr Macro int SIGILL
374 The name of this signal is derived from ``illegal instruction''; it
375 usually means your program is trying to execute garbage or a privileged
376 instruction.  Since the C compiler generates only valid instructions,
377 @code{SIGILL} typically indicates that the executable file is corrupted,
378 or that you are trying to execute data.  Some common ways of getting
379 into the latter situation are by passing an invalid object where a
380 pointer to a function was expected, or by writing past the end of an
381 automatic array (or similar problems with pointers to automatic
382 variables) and corrupting other data on the stack such as the return
383 address of a stack frame.
384
385 @code{SIGILL} can also be generated when the stack overflows, or when
386 the system has trouble running the handler for a signal.
387 @end deftypevr
388 @cindex illegal instruction
389
390 @comment signal.h
391 @comment ISO
392 @deftypevr Macro int SIGSEGV
393 @cindex segmentation violation
394 This signal is generated when a program tries to read or write outside
395 the memory that is allocated for it, or to write memory that can only be
396 read.  (Actually, the signals only occur when the program goes far
397 enough outside to be detected by the system's memory protection
398 mechanism.)  The name is an abbreviation for ``segmentation violation''.
399
400 Common ways of getting a @code{SIGSEGV} condition include dereferencing
401 a null or uninitialized pointer, or when you use a pointer to step
402 through an array, but fail to check for the end of the array.  It varies
403 among systems whether dereferencing a null pointer generates
404 @code{SIGSEGV} or @code{SIGBUS}.
405 @end deftypevr
406
407 @comment signal.h
408 @comment BSD
409 @deftypevr Macro int SIGBUS
410 This signal is generated when an invalid pointer is dereferenced.  Like
411 @code{SIGSEGV}, this signal is typically the result of dereferencing an
412 uninitialized pointer.  The difference between the two is that
413 @code{SIGSEGV} indicates an invalid access to valid memory, while
414 @code{SIGBUS} indicates an access to an invalid address.  In particular,
415 @code{SIGBUS} signals often result from dereferencing a misaligned
416 pointer, such as referring to a four-word integer at an address not
417 divisible by four.  (Each kind of computer has its own requirements for
418 address alignment.)
419
420 The name of this signal is an abbreviation for ``bus error''.
421 @end deftypevr
422 @cindex bus error
423
424 @comment signal.h
425 @comment ISO
426 @deftypevr Macro int SIGABRT
427 @cindex abort signal
428 This signal indicates an error detected by the program itself and
429 reported by calling @code{abort}.  @xref{Aborting a Program}.
430 @end deftypevr
431
432 @comment signal.h
433 @comment Unix
434 @deftypevr Macro int SIGIOT
435 Generated by the PDP-11 ``iot'' instruction.  On most machines, this is
436 just another name for @code{SIGABRT}.
437 @end deftypevr
438
439 @comment signal.h
440 @comment BSD
441 @deftypevr Macro int SIGTRAP
442 Generated by the machine's breakpoint instruction, and possibly other
443 trap instructions.  This signal is used by debuggers.  Your program will
444 probably only see @code{SIGTRAP} if it is somehow executing bad
445 instructions.
446 @end deftypevr
447
448 @comment signal.h
449 @comment BSD
450 @deftypevr Macro int  SIGEMT
451 Emulator trap; this results from certain unimplemented instructions
452 which might be emulated in software, or the operating system's
453 failure to properly emulate them.
454 @end deftypevr
455
456 @comment signal.h
457 @comment Unix
458 @deftypevr Macro int  SIGSYS
459 Bad system call; that is to say, the instruction to trap to the
460 operating system was executed, but the code number for the system call
461 to perform was invalid.
462 @end deftypevr
463
464 @node Termination Signals
465 @subsection Termination Signals
466 @cindex program termination signals
467
468 These signals are all used to tell a process to terminate, in one way
469 or another.  They have different names because they're used for slightly
470 different purposes, and programs might want to handle them differently.
471
472 The reason for handling these signals is usually so your program can
473 tidy up as appropriate before actually terminating.  For example, you
474 might want to save state information, delete temporary files, or restore
475 the previous terminal modes.  Such a handler should end by specifying
476 the default action for the signal that happened and then reraising it;
477 this will cause the program to terminate with that signal, as if it had
478 not had a handler.  (@xref{Termination in Handler}.)
479
480 The (obvious) default action for all of these signals is to cause the
481 process to terminate.
482
483 @comment signal.h
484 @comment ISO
485 @deftypevr Macro int SIGTERM
486 @cindex termination signal
487 The @code{SIGTERM} signal is a generic signal used to cause program
488 termination.  Unlike @code{SIGKILL}, this signal can be blocked,
489 handled, and ignored.  It is the normal way to politely ask a program to
490 terminate.
491
492 The shell command @code{kill} generates @code{SIGTERM} by default.
493 @pindex kill
494 @end deftypevr
495
496 @comment signal.h
497 @comment ISO
498 @deftypevr Macro int SIGINT
499 @cindex interrupt signal
500 The @code{SIGINT} (``program interrupt'') signal is sent when the user
501 types the INTR character (normally @kbd{C-c}).  @xref{Special
502 Characters}, for information about terminal driver support for
503 @kbd{C-c}.
504 @end deftypevr
505
506 @comment signal.h
507 @comment POSIX.1
508 @deftypevr Macro int SIGQUIT
509 @cindex quit signal
510 @cindex quit signal
511 The @code{SIGQUIT} signal is similar to @code{SIGINT}, except that it's
512 controlled by a different key---the QUIT character, usually
513 @kbd{C-\}---and produces a core dump when it terminates the process,
514 just like a program error signal.  You can think of this as a
515 program error condition ``detected'' by the user.
516
517 @xref{Program Error Signals}, for information about core dumps.
518 @xref{Special Characters}, for information about terminal driver
519 support.
520
521 Certain kinds of cleanups are best omitted in handling @code{SIGQUIT}.
522 For example, if the program creates temporary files, it should handle
523 the other termination requests by deleting the temporary files.  But it
524 is better for @code{SIGQUIT} not to delete them, so that the user can
525 examine them in conjunction with the core dump.
526 @end deftypevr
527
528 @comment signal.h
529 @comment POSIX.1
530 @deftypevr Macro int SIGKILL
531 The @code{SIGKILL} signal is used to cause immediate program termination.
532 It cannot be handled or ignored, and is therefore always fatal.  It is
533 also not possible to block this signal.
534
535 This signal is usually generated only by explicit request.  Since it
536 cannot be handled, you should generate it only as a last resort, after
537 first trying a less drastic method such as @kbd{C-c} or @code{SIGTERM}.
538 If a process does not respond to any other termination signals, sending
539 it a @code{SIGKILL} signal will almost always cause it to go away.
540
541 In fact, if @code{SIGKILL} fails to terminate a process, that by itself
542 constitutes an operating system bug which you should report.
543
544 The system will generate @code{SIGKILL} for a process itself under some
545 unusual conditions where the program cannot possible continue to run
546 (even to run a signal handler).
547 @end deftypevr
548 @cindex kill signal
549
550 @comment signal.h
551 @comment POSIX.1
552 @deftypevr Macro int SIGHUP
553 @cindex hangup signal
554 The @code{SIGHUP} (``hang-up'') signal is used to report that the user's
555 terminal is disconnected, perhaps because a network or telephone
556 connection was broken.  For more information about this, see @ref{Control
557 Modes}.
558
559 This signal is also used to report the termination of the controlling
560 process on a terminal to jobs associated with that session; this
561 termination effectively disconnects all processes in the session from
562 the controlling terminal.  For more information, see @ref{Termination
563 Internals}.
564 @end deftypevr
565
566 @node Alarm Signals
567 @subsection Alarm Signals
568
569 These signals are used to indicate the expiration of timers.
570 @xref{Setting an Alarm}, for information about functions that cause
571 these signals to be sent.
572
573 The default behavior for these signals is to cause program termination.
574 This default is rarely useful, but no other default would be useful;
575 most of the ways of using these signals would require handler functions
576 in any case.
577
578 @comment signal.h
579 @comment POSIX.1
580 @deftypevr Macro int SIGALRM
581 This signal typically indicates expiration of a timer that measures real
582 or clock time.  It is used by the @code{alarm} function, for example.
583 @end deftypevr
584 @cindex alarm signal
585
586 @comment signal.h
587 @comment BSD
588 @deftypevr Macro int SIGVTALRM
589 This signal typically indicates expiration of a timer that measures CPU
590 time used by the current process.  The name is an abbreviation for
591 ``virtual time alarm''.
592 @end deftypevr
593 @cindex virtual time alarm signal
594
595 @comment signal.h
596 @comment BSD
597 @deftypevr Macro int SIGPROF
598 This signal is typically indicates expiration of a timer that measures
599 both CPU time used by the current process, and CPU time expended on
600 behalf of the process by the system.  Such a timer is used to implement
601 code profiling facilities, hence the name of this signal.
602 @end deftypevr
603 @cindex profiling alarm signal
604
605
606 @node Asynchronous I/O Signals
607 @subsection Asynchronous I/O Signals
608
609 The signals listed in this section are used in conjunction with
610 asynchronous I/O facilities.  You have to take explicit action by
611 calling @code{fcntl} to enable a particular file descriptor to generate
612 these signals (@pxref{Interrupt Input}).  The default action for these
613 signals is to ignore them.
614
615 @comment signal.h
616 @comment BSD
617 @deftypevr Macro int SIGIO
618 @cindex input available signal
619 @cindex output possible signal
620 This signal is sent when a file descriptor is ready to perform input
621 or output.
622
623 On most operating systems, terminals and sockets are the only kinds of
624 files that can generate @code{SIGIO}; other kinds, including ordinary
625 files, never generate @code{SIGIO} even if you ask them to.
626
627 In the GNU system @code{SIGIO} will always be generated properly
628 if you successfully set asynchronous mode with @code{fcntl}.
629 @end deftypevr
630
631 @comment signal.h
632 @comment BSD
633 @deftypevr Macro int SIGURG
634 @cindex urgent data signal
635 This signal is sent when ``urgent'' or out-of-band data arrives on a
636 socket.  @xref{Out-of-Band Data}.
637 @end deftypevr
638
639 @comment signal.h
640 @comment SVID
641 @deftypevr Macro int SIGPOLL
642 This is a System V signal name, more or less similar to @code{SIGIO}.
643 It is defined only for compatibility.
644 @end deftypevr
645
646 @node Job Control Signals
647 @subsection Job Control Signals
648 @cindex job control signals
649
650 These signals are used to support job control.  If your system
651 doesn't support job control, then these macros are defined but the
652 signals themselves can't be raised or handled.
653
654 You should generally leave these signals alone unless you really
655 understand how job control works.  @xref{Job Control}.
656
657 @comment signal.h
658 @comment POSIX.1
659 @deftypevr Macro int SIGCHLD
660 @cindex child process signal
661 This signal is sent to a parent process whenever one of its child
662 processes terminates or stops.
663
664 The default action for this signal is to ignore it.  If you establish a
665 handler for this signal while there are child processes that have
666 terminated but not reported their status via @code{wait} or
667 @code{waitpid} (@pxref{Process Completion}), whether your new handler
668 applies to those processes or not depends on the particular operating
669 system.
670 @end deftypevr
671
672 @comment signal.h
673 @comment SVID
674 @deftypevr Macro int SIGCLD
675 This is an obsolete name for @code{SIGCHLD}.
676 @end deftypevr
677
678 @comment signal.h
679 @comment POSIX.1
680 @deftypevr Macro int SIGCONT
681 @cindex continue signal
682 You can send a @code{SIGCONT} signal to a process to make it continue.
683 This signal is special---it always makes the process continue if it is
684 stopped, before the signal is delivered.  The default behavior is to do
685 nothing else.  You cannot block this signal.  You can set a handler, but
686 @code{SIGCONT} always makes the process continue regardless.
687
688 Most programs have no reason to handle @code{SIGCONT}; they simply
689 resume execution without realizing they were ever stopped.  You can use
690 a handler for @code{SIGCONT} to make a program do something special when
691 it is stopped and continued---for example, to reprint a prompt when it
692 is suspended while waiting for input.
693 @end deftypevr
694
695 @comment signal.h
696 @comment POSIX.1
697 @deftypevr Macro int SIGSTOP
698 The @code{SIGSTOP} signal stops the process.  It cannot be handled,
699 ignored, or blocked.
700 @end deftypevr
701 @cindex stop signal
702
703 @comment signal.h
704 @comment POSIX.1
705 @deftypevr Macro int SIGTSTP
706 The @code{SIGTSTP} signal is an interactive stop signal.  Unlike
707 @code{SIGSTOP}, this signal can be handled and ignored.
708
709 Your program should handle this signal if you have a special need to
710 leave files or system tables in a secure state when a process is
711 stopped.  For example, programs that turn off echoing should handle
712 @code{SIGTSTP} so they can turn echoing back on before stopping.
713
714 This signal is generated when the user types the SUSP character
715 (normally @kbd{C-z}).  For more information about terminal driver
716 support, see @ref{Special Characters}.
717 @end deftypevr
718 @cindex interactive stop signal
719
720 @comment signal.h
721 @comment POSIX.1
722 @deftypevr Macro int SIGTTIN
723 A process cannot read from the the user's terminal while it is running
724 as a background job.  When any process in a background job tries to
725 read from the terminal, all of the processes in the job are sent a
726 @code{SIGTTIN} signal.  The default action for this signal is to
727 stop the process.  For more information about how this interacts with
728 the terminal driver, see @ref{Access to the Terminal}.
729 @end deftypevr
730 @cindex terminal input signal
731
732 @comment signal.h
733 @comment POSIX.1
734 @deftypevr Macro int SIGTTOU
735 This is similar to @code{SIGTTIN}, but is generated when a process in a
736 background job attempts to write to the terminal or set its modes.
737 Again, the default action is to stop the process.  @code{SIGTTOU} is
738 only generated for an attempt to write to the terminal if the
739 @code{TOSTOP} output mode is set; @pxref{Output Modes}.
740 @end deftypevr
741 @cindex terminal output signal
742
743 While a process is stopped, no more signals can be delivered to it until
744 it is continued, except @code{SIGKILL} signals and (obviously)
745 @code{SIGCONT} signals.  The signals are marked as pending, but not
746 delivered until the process is continued.  The @code{SIGKILL} signal
747 always causes termination of the process and can't be blocked, handled
748 or ignored.  You can ignore @code{SIGCONT}, but it always causes the
749 process to be continued anyway if it is stopped.  Sending a
750 @code{SIGCONT} signal to a process causes any pending stop signals for
751 that process to be discarded.  Likewise, any pending @code{SIGCONT}
752 signals for a process are discarded when it receives a stop signal.
753
754 When a process in an orphaned process group (@pxref{Orphaned Process
755 Groups}) receives a @code{SIGTSTP}, @code{SIGTTIN}, or @code{SIGTTOU}
756 signal and does not handle it, the process does not stop.  Stopping the
757 process would probably not be very useful, since there is no shell
758 program that will notice it stop and allow the user to continue it.
759 What happens instead depends on the operating system you are using.
760 Some systems may do nothing; others may deliver another signal instead,
761 such as @code{SIGKILL} or @code{SIGHUP}.  In the GNU system, the process
762 dies with @code{SIGKILL}; this avoids the problem of many stopped,
763 orphaned processes lying around the system.
764
765 @ignore
766 On the GNU system, it is possible to reattach to the orphaned process
767 group and continue it, so stop signals do stop the process as usual on
768 a GNU system unless you have requested POSIX compatibility ``till it
769 hurts.''
770 @end ignore
771
772 @node Operation Error Signals
773 @subsection Operation Error Signals
774
775 These signals are used to report various errors generated by an
776 operation done by the program.  They do not necessarily indicate a
777 programming error in the program, but an error that prevents an
778 operating system call from completing.  The default action for all of
779 them is to cause the process to terminate.
780
781 @comment signal.h
782 @comment POSIX.1
783 @deftypevr Macro int SIGPIPE
784 @cindex pipe signal
785 @cindex broken pipe signal
786 Broken pipe.  If you use pipes or FIFOs, you have to design your
787 application so that one process opens the pipe for reading before
788 another starts writing.  If the reading process never starts, or
789 terminates unexpectedly, writing to the pipe or FIFO raises a
790 @code{SIGPIPE} signal.  If @code{SIGPIPE} is blocked, handled or
791 ignored, the offending call fails with @code{EPIPE} instead.
792
793 Pipes and FIFO special files are discussed in more detail in @ref{Pipes
794 and FIFOs}.
795
796 Another cause of @code{SIGPIPE} is when you try to output to a socket
797 that isn't connected.  @xref{Sending Data}.
798 @end deftypevr
799
800 @comment signal.h
801 @comment GNU
802 @deftypevr Macro int SIGLOST
803 @cindex lost resource signal
804 Resource lost.  This signal is generated when you have an advisory lock
805 on an NFS file, and the NFS server reboots and forgets about your lock.
806
807 In the GNU system, @code{SIGLOST} is generated when any server program
808 dies unexpectedly.  It is usually fine to ignore the signal; whatever
809 call was made to the server that died just returns an error.
810 @end deftypevr
811
812 @comment signal.h
813 @comment BSD
814 @deftypevr Macro int SIGXCPU
815 CPU time limit exceeded.  This signal is generated when the process
816 exceeds its soft resource limit on CPU time.  @xref{Limits on Resources}.
817 @end deftypevr
818
819 @comment signal.h
820 @comment BSD
821 @deftypevr Macro int SIGXFSZ
822 File size limit exceeded.  This signal is generated when the process
823 attempts to extend a file so it exceeds the process's soft resource
824 limit on file size.  @xref{Limits on Resources}.
825 @end deftypevr
826
827 @node Miscellaneous Signals
828 @subsection Miscellaneous Signals
829
830 These signals are used for various other purposes.  In general, they
831 will not affect your program unless it explicitly uses them for something.
832
833 @comment signal.h
834 @comment POSIX.1
835 @deftypevr Macro int SIGUSR1
836 @end deftypevr
837 @comment signal.h
838 @comment POSIX.1
839 @deftypevr Macro int SIGUSR2
840 @cindex user signals
841 The @code{SIGUSR1} and @code{SIGUSR2} signals are set aside for you to
842 use any way you want.  They're useful for simple interprocess
843 communication, if you write a signal handler for them in the program
844 that receives the signal.
845
846 There is an example showing the use of @code{SIGUSR1} and @code{SIGUSR2}
847 in @ref{Signaling Another Process}.
848
849 The default action is to terminate the process.
850 @end deftypevr
851
852 @comment signal.h
853 @comment BSD
854 @deftypevr Macro int SIGWINCH
855 Window size change.  This is generated on some systems (including GNU)
856 when the terminal driver's record of the number of rows and columns on
857 the screen is changed.  The default action is to ignore it.
858
859 If a program does full-screen display, it should handle @code{SIGWINCH}.
860 When the signal arrives, it should fetch the new screen size and
861 reformat its display accordingly.
862 @end deftypevr
863
864 @comment signal.h
865 @comment BSD
866 @deftypevr Macro int SIGINFO
867 Information request.  In 4.4 BSD and the GNU system, this signal is sent
868 to all the processes in the foreground process group of the controlling
869 terminal when the user types the STATUS character in canonical mode;
870 @pxref{Signal Characters}.
871
872 If the process is the leader of the process group, the default action is
873 to print some status information about the system and what the process
874 is doing.  Otherwise the default is to do nothing.
875 @end deftypevr
876
877 @node Signal Messages
878 @subsection Signal Messages
879 @cindex signal messages
880
881 We mentioned above that the shell prints a message describing the signal
882 that terminated a child process.  The clean way to print a message
883 describing a signal is to use the functions @code{strsignal} and
884 @code{psignal}.  These functions use a signal number to specify which
885 kind of signal to describe.  The signal number may come from the
886 termination status of a child process (@pxref{Process Completion}) or it
887 may come from a signal handler in the same process.
888
889 @comment string.h
890 @comment GNU
891 @deftypefun {char *} strsignal (int @var{signum})
892 This function returns a pointer to a statically-allocated string
893 containing a message describing the signal @var{signum}.  You
894 should not modify the contents of this string; and, since it can be
895 rewritten on subsequent calls, you should save a copy of it if you need
896 to reference it later.
897
898 @pindex string.h
899 This function is a GNU extension, declared in the header file
900 @file{string.h}.
901 @end deftypefun
902
903 @comment signal.h
904 @comment BSD
905 @deftypefun void psignal (int @var{signum}, const char *@var{message})
906 This function prints a message describing the signal @var{signum} to the
907 standard error output stream @code{stderr}; see @ref{Standard Streams}.
908
909 If you call @code{psignal} with a @var{message} that is either a null
910 pointer or an empty string, @code{psignal} just prints the message
911 corresponding to @var{signum}, adding a trailing newline.
912
913 If you supply a non-null @var{message} argument, then @code{psignal}
914 prefixes its output with this string.  It adds a colon and a space
915 character to separate the @var{message} from the string corresponding
916 to @var{signum}.
917
918 @pindex stdio.h
919 This function is a BSD feature, declared in the header file @file{signal.h}.
920 @end deftypefun
921
922 @vindex sys_siglist
923 There is also an array @code{sys_siglist} which contains the messages
924 for the various signal codes.  This array exists on BSD systems, unlike
925 @code{strsignal}.
926
927 @node Signal Actions
928 @section Specifying Signal Actions
929 @cindex signal actions
930 @cindex establishing a handler
931
932 The simplest way to change the action for a signal is to use the
933 @code{signal} function.  You can specify a built-in action (such as to
934 ignore the signal), or you can @dfn{establish a handler}.
935
936 The GNU library also implements the more versatile @code{sigaction}
937 facility.  This section describes both facilities and gives suggestions
938 on which to use when.
939
940 @menu
941 * Basic Signal Handling::       The simple @code{signal} function.
942 * Advanced Signal Handling::    The more powerful @code{sigaction} function.
943 * Signal and Sigaction::        How those two functions interact.
944 * Sigaction Function Example::  An example of using the sigaction function.
945 * Flags for Sigaction::         Specifying options for signal handling.
946 * Initial Signal Actions::      How programs inherit signal actions.
947 @end menu
948
949 @node Basic Signal Handling
950 @subsection Basic Signal Handling
951 @cindex @code{signal} function
952
953 The @code{signal} function provides a simple interface for establishing
954 an action for a particular signal.  The function and associated macros
955 are declared in the header file @file{signal.h}.
956 @pindex signal.h
957
958 @comment signal.h
959 @comment GNU
960 @deftp {Data Type} sighandler_t
961 This is the type of signal handler functions.  Signal handlers take one
962 integer argument specifying the signal number, and have return type
963 @code{void}.  So, you should define handler functions like this:
964
965 @smallexample
966 void @var{handler} (int @code{signum}) @{ @dots{} @}
967 @end smallexample
968
969 The name @code{sighandler_t} for this data type is a GNU extension.
970 @end deftp
971
972 @comment signal.h
973 @comment ISO
974 @deftypefun sighandler_t signal (int @var{signum}, sighandler_t @var{action})
975 The @code{signal} function establishes @var{action} as the action for
976 the signal @var{signum}.
977
978 The first argument, @var{signum}, identifies the signal whose behavior
979 you want to control, and should be a signal number.  The proper way to
980 specify a signal number is with one of the symbolic signal names
981 described in @ref{Standard Signals}---don't use an explicit number, because
982 the numerical code for a given kind of signal may vary from operating
983 system to operating system.
984
985 The second argument, @var{action}, specifies the action to use for the
986 signal @var{signum}.  This can be one of the following:
987
988 @table @code
989 @item SIG_DFL
990 @vindex SIG_DFL
991 @cindex default action for a signal
992 @code{SIG_DFL} specifies the default action for the particular signal.
993 The default actions for various kinds of signals are stated in
994 @ref{Standard Signals}.
995
996 @item SIG_IGN
997 @vindex SIG_IGN
998 @cindex ignore action for a signal
999 @code{SIG_IGN} specifies that the signal should be ignored.
1000
1001 Your program generally should not ignore signals that represent serious
1002 events or that are normally used to request termination.  You cannot
1003 ignore the @code{SIGKILL} or @code{SIGSTOP} signals at all.  You can
1004 ignore program error signals like @code{SIGSEGV}, but ignoring the error
1005 won't enable the program to continue executing meaningfully.  Ignoring
1006 user requests such as @code{SIGINT}, @code{SIGQUIT}, and @code{SIGTSTP}
1007 is unfriendly.
1008
1009 When you do not wish signals to be delivered during a certain part of
1010 the program, the thing to do is to block them, not ignore them.
1011 @xref{Blocking Signals}.
1012
1013 @item @var{handler}
1014 Supply the address of a handler function in your program, to specify
1015 running this handler as the way to deliver the signal.
1016
1017 For more information about defining signal handler functions,
1018 see @ref{Defining Handlers}.
1019 @end table
1020
1021 If you set the action for a signal to @code{SIG_IGN}, or if you set it
1022 to @code{SIG_DFL} and the default action is to ignore that signal, then
1023 any pending signals of that type are discarded (even if they are
1024 blocked).  Discarding the pending signals means that they will never be
1025 delivered, not even if you subsequently specify another action and
1026 unblock this kind of signal.
1027
1028 The @code{signal} function returns the action that was previously in
1029 effect for the specified @var{signum}.  You can save this value and
1030 restore it later by calling @code{signal} again.
1031
1032 If @code{signal} can't honor the request, it returns @code{SIG_ERR}
1033 instead.  The following @code{errno} error conditions are defined for
1034 this function:
1035
1036 @table @code
1037 @item EINVAL
1038 You specified an invalid @var{signum}; or you tried to ignore or provide
1039 a handler for @code{SIGKILL} or @code{SIGSTOP}.
1040 @end table
1041 @end deftypefun
1042
1043 Here is a simple example of setting up a handler to delete temporary
1044 files when certain fatal signals happen:
1045
1046 @smallexample
1047 #include <signal.h>
1048
1049 void
1050 termination_handler (int signum)
1051 @{
1052   struct temp_file *p;
1053
1054   for (p = temp_file_list; p; p = p->next)
1055     unlink (p->name);
1056 @}
1057
1058 int
1059 main (void)
1060 @{
1061   @dots{}
1062   if (signal (SIGINT, termination_handler) == SIG_IGN)
1063     signal (SIGINT, SIG_IGN);
1064   if (signal (SIGHUP, termination_handler) == SIG_IGN)
1065     signal (SIGHUP, SIG_IGN);
1066   if (signal (SIGTERM, termination_handler) == SIG_IGN)
1067     signal (SIGTERM, SIG_IGN);
1068   @dots{}
1069 @}
1070 @end smallexample
1071
1072 @noindent
1073 Note how if a given signal was previously set to be ignored, this code
1074 avoids altering that setting.  This is because non-job-control shells
1075 often ignore certain signals when starting children, and it is important
1076 for the children to respect this.
1077
1078 We do not handle @code{SIGQUIT} or the program error signals in this
1079 example because these are designed to provide information for debugging
1080 (a core dump), and the temporary files may give useful information.
1081
1082 @comment signal.h
1083 @comment SVID
1084 @deftypefun sighandler_t ssignal (int @var{signum}, sighandler_t @var{action})
1085 The @code{ssignal} function does the same thing as @code{signal}; it is
1086 provided only for compatibility with SVID.
1087 @end deftypefun
1088
1089 @comment signal.h
1090 @comment ISO
1091 @deftypevr Macro sighandler_t SIG_ERR
1092 The value of this macro is used as the return value from @code{signal}
1093 to indicate an error.
1094 @end deftypevr
1095
1096 @ignore
1097 @comment RMS says that ``we don't do this''.
1098 Implementations might define additional macros for built-in signal
1099 actions that are suitable as a @var{action} argument to @code{signal},
1100 besides @code{SIG_IGN} and @code{SIG_DFL}.  Identifiers whose names
1101 begin with @samp{SIG_} followed by an uppercase letter are reserved for
1102 this purpose.
1103 @end ignore
1104
1105
1106 @node Advanced Signal Handling
1107 @subsection Advanced Signal Handling
1108 @cindex @code{sigaction} function
1109
1110 The @code{sigaction} function has the same basic effect as
1111 @code{signal}: to specify how a signal should be handled by the process.
1112 However, @code{sigaction} offers more control, at the expense of more
1113 complexity.  In particular, @code{sigaction} allows you to specify
1114 additional flags to control when the signal is generated and how the
1115 handler is invoked.
1116
1117 The @code{sigaction} function is declared in @file{signal.h}.
1118 @pindex signal.h
1119
1120 @comment signal.h
1121 @comment POSIX.1
1122 @deftp {Data Type} {struct sigaction}
1123 Structures of type @code{struct sigaction} are used in the
1124 @code{sigaction} function to specify all the information about how to
1125 handle a particular signal.  This structure contains at least the
1126 following members:
1127
1128 @table @code
1129 @item sighandler_t sa_handler
1130 This is used in the same way as the @var{action} argument to the
1131 @code{signal} function.  The value can be @code{SIG_DFL},
1132 @code{SIG_IGN}, or a function pointer.  @xref{Basic Signal Handling}.
1133
1134 @item sigset_t sa_mask
1135 This specifies a set of signals to be blocked while the handler runs.
1136 Blocking is explained in @ref{Blocking for Handler}.  Note that the
1137 signal that was delivered is automatically blocked by default before its
1138 handler is started; this is true regardless of the value in
1139 @code{sa_mask}.  If you want that signal not to be blocked within its
1140 handler, you must write code in the handler to unblock it.
1141
1142 @item int sa_flags
1143 This specifies various flags which can affect the behavior of
1144 the signal.  These are described in more detail in @ref{Flags for Sigaction}.
1145 @end table
1146 @end deftp
1147
1148 @comment signal.h
1149 @comment POSIX.1
1150 @deftypefun int sigaction (int @var{signum}, const struct sigaction *@var{action}, struct sigaction *@var{old-action})
1151 The @var{action} argument is used to set up a new action for the signal
1152 @var{signum}, while the @var{old-action} argument is used to return
1153 information about the action previously associated with this symbol.
1154 (In other words, @var{old-action} has the same purpose as the
1155 @code{signal} function's return value---you can check to see what the
1156 old action in effect for the signal was, and restore it later if you
1157 want.)
1158
1159 Either @var{action} or @var{old-action} can be a null pointer.  If
1160 @var{old-action} is a null pointer, this simply suppresses the return
1161 of information about the old action.  If @var{action} is a null pointer,
1162 the action associated with the signal @var{signum} is unchanged; this
1163 allows you to inquire about how a signal is being handled without changing
1164 that handling.
1165
1166 The return value from @code{sigaction} is zero if it succeeds, and
1167 @code{-1} on failure.  The following @code{errno} error conditions are
1168 defined for this function:
1169
1170 @table @code
1171 @item EINVAL
1172 The @var{signum} argument is not valid, or you are trying to
1173 trap or ignore @code{SIGKILL} or @code{SIGSTOP}.
1174 @end table
1175 @end deftypefun
1176
1177 @node Signal and Sigaction
1178 @subsection Interaction of @code{signal} and @code{sigaction}
1179
1180 It's possible to use both the @code{signal} and @code{sigaction}
1181 functions within a single program, but you have to be careful because
1182 they can interact in slightly strange ways.
1183
1184 The @code{sigaction} function specifies more information than the
1185 @code{signal} function, so the return value from @code{signal} cannot
1186 express the full range of @code{sigaction} possibilities.  Therefore, if
1187 you use @code{signal} to save and later reestablish an action, it may
1188 not be able to reestablish properly a handler that was established with
1189 @code{sigaction}.
1190
1191 To avoid having problems as a result, always use @code{sigaction} to
1192 save and restore a handler if your program uses @code{sigaction} at all.
1193 Since @code{sigaction} is more general, it can properly save and
1194 reestablish any action, regardless of whether it was established
1195 originally with @code{signal} or @code{sigaction}.
1196
1197 On some systems if you establish an action with @code{signal} and then
1198 examine it with @code{sigaction}, the handler address that you get may
1199 not be the same as what you specified with @code{signal}.  It may not
1200 even be suitable for use as an action argument with @code{signal}.  But
1201 you can rely on using it as an argument to @code{sigaction}.  This
1202 problem never happens on the GNU system.
1203
1204 So, you're better off using one or the other of the mechanisms
1205 consistently within a single program.
1206
1207 @strong{Portability Note:} The basic @code{signal} function is a feature
1208 of @w{ISO C}, while @code{sigaction} is part of the POSIX.1 standard.  If
1209 you are concerned about portability to non-POSIX systems, then you
1210 should use the @code{signal} function instead.
1211
1212 @node Sigaction Function Example
1213 @subsection @code{sigaction} Function Example
1214
1215 In @ref{Basic Signal Handling}, we gave an example of establishing a
1216 simple handler for termination signals using @code{signal}.  Here is an
1217 equivalent example using @code{sigaction}:
1218
1219 @smallexample
1220 #include <signal.h>
1221
1222 void
1223 termination_handler (int signum)
1224 @{
1225   struct temp_file *p;
1226
1227   for (p = temp_file_list; p; p = p->next)
1228     unlink (p->name);
1229 @}
1230
1231 int
1232 main (void)
1233 @{
1234   @dots{}
1235   struct sigaction new_action, old_action;
1236
1237   /* @r{Set up the structure to specify the new action.} */
1238   new_action.sa_handler = termination_handler;
1239   sigemptyset (&new_action.sa_mask);
1240   new_action.sa_flags = 0;
1241
1242   sigaction (SIGINT, NULL, &old_action);
1243   if (old_action.sa_handler != SIG_IGN)
1244     sigaction (SIGINT, &new_action, NULL);
1245   sigaction (SIGHUP, NULL, &old_action);
1246   if (old_action.sa_handler != SIG_IGN)
1247     sigaction (SIGHUP, &new_action, NULL);
1248   sigaction (SIGTERM, NULL, &old_action);
1249   if (old_action.sa_handler != SIG_IGN)
1250     sigaction (SIGTERM, &new_action, NULL);
1251   @dots{}
1252 @}
1253 @end smallexample
1254
1255 The program just loads the @code{new_action} structure with the desired
1256 parameters and passes it in the @code{sigaction} call.  The usage of
1257 @code{sigemptyset} is described later; see @ref{Blocking Signals}.
1258
1259 As in the example using @code{signal}, we avoid handling signals
1260 previously set to be ignored.  Here we can avoid altering the signal
1261 handler even momentarily, by using the feature of @code{sigaction} that
1262 lets us examine the current action without specifying a new one.
1263
1264 Here is another example.  It retrieves information about the current
1265 action for @code{SIGINT} without changing that action.
1266
1267 @smallexample
1268 struct sigaction query_action;
1269
1270 if (sigaction (SIGINT, NULL, &query_action) < 0)
1271   /* @r{@code{sigaction} returns -1 in case of error.} */
1272 else if (query_action.sa_handler == SIG_DFL)
1273   /* @r{@code{SIGINT} is handled in the default, fatal manner.} */
1274 else if (query_action.sa_handler == SIG_IGN)
1275   /* @r{@code{SIGINT} is ignored.} */
1276 else
1277   /* @r{A programmer-defined signal handler is in effect.} */
1278 @end smallexample
1279
1280 @node Flags for Sigaction
1281 @subsection Flags for @code{sigaction}
1282 @cindex signal flags
1283 @cindex flags for @code{sigaction}
1284 @cindex @code{sigaction} flags
1285
1286 The @code{sa_flags} member of the @code{sigaction} structure is a
1287 catch-all for special features.  Most of the time, @code{SA_RESTART} is
1288 a good value to use for this field.
1289
1290 The value of @code{sa_flags} is interpreted as a bit mask.  Thus, you
1291 should choose the flags you want to set, @sc{or} those flags together,
1292 and store the result in the @code{sa_flags} member of your
1293 @code{sigaction} structure.
1294
1295 Each signal number has its own set of flags.  Each call to
1296 @code{sigaction} affects one particular signal number, and the flags
1297 that you specify apply only to that particular signal.
1298
1299 In the GNU C library, establishing a handler with @code{signal} sets all
1300 the flags to zero except for @code{SA_RESTART}, whose value depends on
1301 the settings you have made with @code{siginterrupt}.  @xref{Interrupted
1302 Primitives}, to see what this is about.
1303
1304 @pindex signal.h
1305 These macros are defined in the header file @file{signal.h}.
1306
1307 @comment signal.h
1308 @comment POSIX.1
1309 @deftypevr Macro int SA_NOCLDSTOP
1310 This flag is meaningful only for the @code{SIGCHLD} signal.  When the
1311 flag is set, the system delivers the signal for a terminated child
1312 process but not for one that is stopped.  By default, @code{SIGCHLD} is
1313 delivered for both terminated children and stopped children.
1314
1315 Setting this flag for a signal other than @code{SIGCHLD} has no effect.
1316 @end deftypevr
1317
1318 @comment signal.h
1319 @comment BSD
1320 @deftypevr Macro int SA_ONSTACK
1321 If this flag is set for a particular signal number, the system uses the
1322 signal stack when delivering that kind of signal.  @xref{Signal Stack}.
1323 If a signal with this flag arrives and you have not set a signal stack,
1324 the system terminates the program with @code{SIGILL}.
1325 @end deftypevr
1326
1327 @comment signal.h
1328 @comment BSD
1329 @deftypevr Macro int SA_RESTART
1330 This flag controls what happens when a signal is delivered during
1331 certain primitives (such as @code{open}, @code{read} or @code{write}),
1332 and the signal handler returns normally.  There are two alternatives:
1333 the library function can resume, or it can return failure with error
1334 code @code{EINTR}.
1335
1336 The choice is controlled by the @code{SA_RESTART} flag for the
1337 particular kind of signal that was delivered.  If the flag is set,
1338 returning from a handler resumes the library function.  If the flag is
1339 clear, returning from a handler makes the function fail.
1340 @xref{Interrupted Primitives}.
1341 @end deftypevr
1342
1343 @node Initial Signal Actions
1344 @subsection Initial Signal Actions
1345 @cindex initial signal actions
1346
1347 When a new process is created (@pxref{Creating a Process}), it inherits
1348 handling of signals from its parent process.  However, when you load a
1349 new process image using the @code{exec} function (@pxref{Executing a
1350 File}), any signals that you've defined your own handlers for revert to
1351 their @code{SIG_DFL} handling.  (If you think about it a little, this
1352 makes sense; the handler functions from the old program are specific to
1353 that program, and aren't even present in the address space of the new
1354 program image.)  Of course, the new program can establish its own
1355 handlers.
1356
1357 When a program is run by a shell, the shell normally sets the initial
1358 actions for the child process to @code{SIG_DFL} or @code{SIG_IGN}, as
1359 appropriate.  It's a good idea to check to make sure that the shell has
1360 not set up an initial action of @code{SIG_IGN} before you establish your
1361 own signal handlers.
1362
1363 Here is an example of how to establish a handler for @code{SIGHUP}, but
1364 not if @code{SIGHUP} is currently ignored:
1365
1366 @smallexample
1367 @group
1368 @dots{}
1369 struct sigaction temp;
1370
1371 sigaction (SIGHUP, NULL, &temp);
1372
1373 if (temp.sa_handler != SIG_IGN)
1374   @{
1375     temp.sa_handler = handle_sighup;
1376     sigemptyset (&temp.sa_mask);
1377     sigaction (SIGHUP, &temp, NULL);
1378   @}
1379 @end group
1380 @end smallexample
1381
1382 @node Defining Handlers
1383 @section Defining Signal Handlers
1384 @cindex signal handler function
1385
1386 This section describes how to write a signal handler function that can
1387 be established with the @code{signal} or @code{sigaction} functions.
1388
1389 A signal handler is just a function that you compile together with the
1390 rest of the program.  Instead of directly invoking the function, you use
1391 @code{signal} or @code{sigaction} to tell the operating system to call
1392 it when a signal arrives.  This is known as @dfn{establishing} the
1393 handler.  @xref{Signal Actions}.
1394
1395 There are two basic strategies you can use in signal handler functions:
1396
1397 @itemize @bullet
1398 @item
1399 You can have the handler function note that the signal arrived by
1400 tweaking some global data structures, and then return normally.
1401
1402 @item
1403 You can have the handler function terminate the program or transfer
1404 control to a point where it can recover from the situation that caused
1405 the signal.
1406 @end itemize
1407
1408 You need to take special care in writing handler functions because they
1409 can be called asynchronously.  That is, a handler might be called at any
1410 point in the program, unpredictably.  If two signals arrive during a
1411 very short interval, one handler can run within another.  This section
1412 describes what your handler should do, and what you should avoid.
1413
1414 @menu
1415 * Handler Returns::             Handlers that return normally, and what
1416                                  this means.
1417 * Termination in Handler::      How handler functions terminate a program.
1418 * Longjmp in Handler::          Nonlocal transfer of control out of a
1419                                  signal handler.
1420 * Signals in Handler::          What happens when signals arrive while
1421                                  the handler is already occupied.
1422 * Merged Signals::              When a second signal arrives before the
1423                                  first is handled.
1424 * Nonreentrancy::               Do not call any functions unless you know they
1425                                  are reentrant with respect to signals.
1426 * Atomic Data Access::          A single handler can run in the middle of
1427                                  reading or writing a single object.
1428 @end menu
1429
1430 @node Handler Returns
1431 @subsection Signal Handlers that Return
1432
1433 Handlers which return normally are usually used for signals such as
1434 @code{SIGALRM} and the I/O and interprocess communication signals.  But
1435 a handler for @code{SIGINT} might also return normally after setting a
1436 flag that tells the program to exit at a convenient time.
1437
1438 It is not safe to return normally from the handler for a program error
1439 signal, because the behavior of the program when the handler function
1440 returns is not defined after a program error.  @xref{Program Error
1441 Signals}.
1442
1443 Handlers that return normally must modify some global variable in order
1444 to have any effect.  Typically, the variable is one that is examined
1445 periodically by the program during normal operation.  Its data type
1446 should be @code{sig_atomic_t} for reasons described in @ref{Atomic
1447 Data Access}.
1448
1449 Here is a simple example of such a program.  It executes the body of
1450 the loop until it has noticed that a @code{SIGALRM} signal has arrived.
1451 This technique is useful because it allows the iteration in progress
1452 when the signal arrives to complete before the loop exits.
1453
1454 @smallexample
1455 @include sigh1.c.texi
1456 @end smallexample
1457
1458 @node Termination in Handler
1459 @subsection Handlers That Terminate the Process
1460
1461 Handler functions that terminate the program are typically used to cause
1462 orderly cleanup or recovery from program error signals and interactive
1463 interrupts.
1464
1465 The cleanest way for a handler to terminate the process is to raise the
1466 same signal that ran the handler in the first place.  Here is how to do
1467 this:
1468
1469 @smallexample
1470 volatile sig_atomic_t fatal_error_in_progress = 0;
1471
1472 void
1473 fatal_error_signal (int sig)
1474 @{
1475 @group
1476   /* @r{Since this handler is established for more than one kind of signal, }
1477      @r{it might still get invoked recursively by delivery of some other kind}
1478      @r{of signal.  Use a static variable to keep track of that.} */
1479   if (fatal_error_in_progress)
1480     raise (sig);
1481   fatal_error_in_progress = 1;
1482 @end group
1483
1484 @group
1485   /* @r{Now do the clean up actions:}
1486      @r{- reset terminal modes}
1487      @r{- kill child processes}
1488      @r{- remove lock files} */
1489   @dots{}
1490 @end group
1491
1492 @group
1493   /* @r{Now reraise the signal.  Since the signal is blocked,}
1494      @r{it will receive its default handling, which is}
1495      @r{to terminate the process.  We could just call}
1496      @r{@code{exit} or @code{abort}, but reraising the signal}
1497      @r{sets the return status from the process correctly.} */
1498   raise (sig);
1499 @}
1500 @end group
1501 @end smallexample
1502
1503 @node Longjmp in Handler
1504 @subsection Nonlocal Control Transfer in Handlers
1505 @cindex non-local exit, from signal handler
1506
1507 You can do a nonlocal transfer of control out of a signal handler using
1508 the @code{setjmp} and @code{longjmp} facilities (@pxref{Non-Local
1509 Exits}).
1510
1511 When the handler does a nonlocal control transfer, the part of the
1512 program that was running will not continue.  If this part of the program
1513 was in the middle of updating an important data structure, the data
1514 structure will remain inconsistent.  Since the program does not
1515 terminate, the inconsistency is likely to be noticed later on.
1516
1517 There are two ways to avoid this problem.  One is to block the signal
1518 for the parts of the program that update important data structures.
1519 Blocking the signal delays its delivery until it is unblocked, once the
1520 critical updating is finished.  @xref{Blocking Signals}.
1521
1522 The other way to re-initialize the crucial data structures in the signal
1523 handler, or make their values consistent.
1524
1525 Here is a rather schematic example showing the reinitialization of one
1526 global variable.
1527
1528 @smallexample
1529 @group
1530 #include <signal.h>
1531 #include <setjmp.h>
1532
1533 jmp_buf return_to_top_level;
1534
1535 volatile sig_atomic_t waiting_for_input;
1536
1537 void
1538 handle_sigint (int signum)
1539 @{
1540   /* @r{We may have been waiting for input when the signal arrived,}
1541      @r{but we are no longer waiting once we transfer control.} */
1542   waiting_for_input = 0;
1543   longjmp (return_to_top_level, 1);
1544 @}
1545 @end group
1546
1547 @group
1548 int
1549 main (void)
1550 @{
1551   @dots{}
1552   signal (SIGINT, sigint_handler);
1553   @dots{}
1554   while (1) @{
1555     prepare_for_command ();
1556     if (setjmp (return_to_top_level) == 0)
1557       read_and_execute_command ();
1558   @}
1559 @}
1560 @end group
1561
1562 @group
1563 /* @r{Imagine this is a subroutine used by various commands.} */
1564 char *
1565 read_data ()
1566 @{
1567   if (input_from_terminal) @{
1568     waiting_for_input = 1;
1569     @dots{}
1570     waiting_for_input = 0;
1571   @} else @{
1572     @dots{}
1573   @}
1574 @}
1575 @end group
1576 @end smallexample
1577
1578
1579 @node Signals in Handler
1580 @subsection Signals Arriving While a Handler Runs
1581 @cindex race conditions, relating to signals
1582
1583 What happens if another signal arrives while your signal handler
1584 function is running?
1585
1586 When the handler for a particular signal is invoked, that signal is
1587 automatically blocked until the handler returns.  That means that if two
1588 signals of the same kind arrive close together, the second one will be
1589 held until the first has been handled.  (The handler can explicitly
1590 unblock the signal using @code{sigprocmask}, if you want to allow more
1591 signals of this type to arrive; see @ref{Process Signal Mask}.)
1592
1593 However, your handler can still be interrupted by delivery of another
1594 kind of signal.  To avoid this, you can use the @code{sa_mask} member of
1595 the action structure passed to @code{sigaction} to explicitly specify
1596 which signals should be blocked while the signal handler runs.  These
1597 signals are in addition to the signal for which the handler was invoked,
1598 and any other signals that are normally blocked by the process.
1599 @xref{Blocking for Handler}.
1600
1601 When the handler returns, the set of blocked signals is restored to the
1602 value it had before the handler ran.  So using @code{sigprocmask} inside
1603 the handler only affects what signals can arrive during the execution of
1604 the handler itself, not what signals can arrive once the handler returns.
1605
1606 @strong{Portability Note:} Always use @code{sigaction} to establish a
1607 handler for a signal that you expect to receive asynchronously, if you
1608 want your program to work properly on System V Unix.  On this system,
1609 the handling of a signal whose handler was established with
1610 @code{signal} automatically sets the signal's action back to
1611 @code{SIG_DFL}, and the handler must re-establish itself each time it
1612 runs.  This practice, while inconvenient, does work when signals cannot
1613 arrive in succession.  However, if another signal can arrive right away,
1614 it may arrive before the handler can re-establish itself.  Then the
1615 second signal would receive the default handling, which could terminate
1616 the process.
1617
1618 @node Merged Signals
1619 @subsection Signals Close Together Merge into One
1620 @cindex handling multiple signals
1621 @cindex successive signals
1622 @cindex merging of signals
1623
1624 If multiple signals of the same type are delivered to your process
1625 before your signal handler has a chance to be invoked at all, the
1626 handler may only be invoked once, as if only a single signal had
1627 arrived.  In effect, the signals merge into one.  This situation can
1628 arise when the signal is blocked, or in a multiprocessing environment
1629 where the system is busy running some other processes while the signals
1630 are delivered.  This means, for example, that you cannot reliably use a
1631 signal handler to count signals.  The only distinction you can reliably
1632 make is whether at least one signal has arrived since a given time in
1633 the past.
1634
1635 Here is an example of a handler for @code{SIGCHLD} that compensates for
1636 the fact that the number of signals recieved may not equal the number of
1637 child processes generate them.  It assumes that the program keeps track
1638 of all the child processes with a chain of structures as follows:
1639
1640 @smallexample
1641 struct process
1642 @{
1643   struct process *next;
1644   /* @r{The process ID of this child.}  */
1645   int pid;
1646   /* @r{The descriptor of the pipe or pseudo terminal}
1647      @r{on which output comes from this child.}  */
1648   int input_descriptor;
1649   /* @r{Nonzero if this process has stopped or terminated.}  */
1650   sig_atomic_t have_status;
1651   /* @r{The status of this child; 0 if running,}
1652      @r{otherwise a status value from @code{waitpid}.}  */
1653   int status;
1654 @};
1655
1656 struct process *process_list;
1657 @end smallexample
1658
1659 This example also uses a flag to indicate whether signals have arrived
1660 since some time in the past---whenever the program last cleared it to
1661 zero.
1662
1663 @smallexample
1664 /* @r{Nonzero means some child's status has changed}
1665    @r{so look at @code{process_list} for the details.}  */
1666 int process_status_change;
1667 @end smallexample
1668
1669 Here is the handler itself:
1670
1671 @smallexample
1672 void
1673 sigchld_handler (int signo)
1674 @{
1675   int old_errno = errno;
1676
1677   while (1) @{
1678     register int pid;
1679     int w;
1680     struct process *p;
1681
1682     /* @r{Keep asking for a status until we get a definitive result.}  */
1683     do
1684       @{
1685         errno = 0;
1686         pid = waitpid (WAIT_ANY, &w, WNOHANG | WUNTRACED);
1687       @}
1688     while (pid <= 0 && errno == EINTR);
1689
1690     if (pid <= 0) @{
1691       /* @r{A real failure means there are no more}
1692          @r{stopped or terminated child processes, so return.}  */
1693       errno = old_errno;
1694       return;
1695     @}
1696
1697     /* @r{Find the process that signaled us, and record its status.}  */
1698
1699     for (p = process_list; p; p = p->next)
1700       if (p->pid == pid) @{
1701         p->status = w;
1702         /* @r{Indicate that the @code{status} field}
1703            @r{has data to look at.  We do this only after storing it.}  */
1704         p->have_status = 1;
1705
1706         /* @r{If process has terminated, stop waiting for its output.}  */
1707         if (WIFSIGNALED (w) || WIFEXITED (w))
1708           if (p->input_descriptor)
1709             FD_CLR (p->input_descriptor, &input_wait_mask);
1710
1711         /* @r{The program should check this flag from time to time}
1712            @r{to see if there is any news in @code{process_list}.}  */
1713         ++process_status_change;
1714       @}
1715
1716     /* @r{Loop around to handle all the processes}
1717        @r{that have something to tell us.}  */
1718   @}
1719 @}
1720 @end smallexample
1721
1722 Here is the proper way to check the flag @code{process_status_change}:
1723
1724 @smallexample
1725 if (process_status_change) @{
1726   struct process *p;
1727   process_status_change = 0;
1728   for (p = process_list; p; p = p->next)
1729     if (p->have_status) @{
1730       @dots{} @r{Examine @code{p->status}} @dots{}
1731     @}
1732 @}
1733 @end smallexample
1734
1735 @noindent
1736 It is vital to clear the flag before examining the list; otherwise, if a
1737 signal were delivered just before the clearing of the flag, and after
1738 the appropriate element of the process list had been checked, the status
1739 change would go unnoticed until the next signal arrived to set the flag
1740 again.  You could, of course, avoid this problem by blocking the signal
1741 while scanning the list, but it is much more elegant to guarantee
1742 correctness by doing things in the right order.
1743
1744 The loop which checks process status avoids examining @code{p->status}
1745 until it sees that status has been validly stored.  This is to make sure
1746 that the status cannot change in the middle of accessing it.  Once
1747 @code{p->have_status} is set, it means that the child process is stopped
1748 or terminated, and in either case, it cannot stop or terminate again
1749 until the program has taken notice.  @xref{Atomic Usage}, for more
1750 information about coping with interruptions during accessings of a
1751 variable.
1752
1753 Here is another way you can test whether the handler has run since the
1754 last time you checked.  This technique uses a counter which is never
1755 changed outside the handler.  Instead of clearing the count, the program
1756 remembers the previous value and sees whether it has changed since the
1757 previous check.  The advantage of this method is that different parts of
1758 the program can check independently, each part checking whether there
1759 has been a signal since that part last checked.
1760
1761 @smallexample
1762 sig_atomic_t process_status_change;
1763
1764 sig_atomic_t last_process_status_change;
1765
1766 @dots{}
1767 @{
1768   sig_atomic_t prev = last_process_status_change;
1769   last_process_status_change = process_status_change;
1770   if (last_process_status_change != prev) @{
1771     struct process *p;
1772     for (p = process_list; p; p = p->next)
1773       if (p->have_status) @{
1774         @dots{} @r{Examine @code{p->status}} @dots{}
1775       @}
1776   @}
1777 @}
1778 @end smallexample
1779
1780 @node Nonreentrancy
1781 @subsection Signal Handling and Nonreentrant Functions
1782 @cindex restrictions on signal handler functions
1783
1784 Handler functions usually don't do very much.  The best practice is to
1785 write a handler that does nothing but set an external variable that the
1786 program checks regularly, and leave all serious work to the program.
1787 This is best because the handler can be called at asynchronously, at
1788 unpredictable times---perhaps in the middle of a primitive function, or
1789 even between the beginning and the end of a C operator that requires
1790 multiple instructions.  The data structures being manipulated might
1791 therefore be in an inconsistent state when the handler function is
1792 invoked.  Even copying one @code{int} variable into another can take two
1793 instructions on most machines.
1794
1795 This means you have to be very careful about what you do in a signal
1796 handler.
1797
1798 @itemize @bullet
1799 @item
1800 @cindex @code{volatile} declarations
1801 If your handler needs to access any global variables from your program,
1802 declare those variables @code{volatile}.  This tells the compiler that
1803 the value of the variable might change asynchronously, and inhibits
1804 certain optimizations that would be invalidated by such modifications.
1805
1806 @item
1807 @cindex reentrant functions
1808 If you call a function in the handler, make sure it is @dfn{reentrant}
1809 with respect to signals, or else make sure that the signal cannot
1810 interrupt a call to a related function.
1811 @end itemize
1812
1813 A function can be non-reentrant if it uses memory that is not on the
1814 stack.
1815
1816 @itemize @bullet
1817 @item
1818 If a function uses a static variable or a global variable, or a
1819 dynamically-allocated object that it finds for itself, then it is
1820 non-reentrant and any two calls to the function can interfere.
1821
1822 For example, suppose that the signal handler uses @code{gethostbyname}.
1823 This function returns its value in a static object, reusing the same
1824 object each time.  If the signal happens to arrive during a call to
1825 @code{gethostbyname}, or even after one (while the program is still
1826 using the value), it will clobber the value that the program asked for.
1827
1828 However, if the program does not use @code{gethostbyname} or any other
1829 function that returns information in the same object, or if it always
1830 blocks signals around each use, then you are safe.
1831
1832 There are a large number of library functions that return values in a
1833 fixed object, always reusing the same object in this fashion, and all of
1834 them cause the same problem.  The description of a function in this
1835 manual always mentions this behavior.
1836
1837 @item
1838 If a function uses and modifies an object that you supply, then it is
1839 potentially non-reentrant; two calls can interfere if they use the same
1840 object.
1841
1842 This case arises when you do I/O using streams.  Suppose that the
1843 signal handler prints a message with @code{fprintf}.  Suppose that the
1844 program was in the middle of an @code{fprintf} call using the same
1845 stream when the signal was delivered.  Both the signal handler's message
1846 and the program's data could be corrupted, because both calls operate on
1847 the same data structure---the stream itself.
1848
1849 However, if you know that the stream that the handler uses cannot
1850 possibly be used by the program at a time when signals can arrive, then
1851 you are safe.  It is no problem if the program uses some other stream.
1852
1853 @item
1854 On most systems, @code{malloc} and @code{free} are not reentrant,
1855 because they use a static data structure which records what memory
1856 blocks are free.  As a result, no library functions that allocate or
1857 free memory are reentrant.  This includes functions that allocate space
1858 to store a result.
1859
1860 The best way to avoid the need to allocate memory in a handler is to
1861 allocate in advance space for signal handlers to use.
1862
1863 The best way to avoid freeing memory in a handler is to flag or record
1864 the objects to be freed, and have the program check from time to time
1865 whether anything is waiting to be freed.  But this must be done with
1866 care, because placing an object on a chain is not atomic, and if it is
1867 interrupted by another signal handler that does the same thing, you
1868 could ``lose'' one of the objects.
1869
1870 @ignore
1871 !!! not true
1872 On the GNU system, @code{malloc} and @code{free} are safe to use in
1873 signal handlers because they block signals.  As a result, the library
1874 functions that allocate space for a result are also safe in signal
1875 handlers.  The obstack allocation functions are safe as long as you
1876 don't use the same obstack both inside and outside of a signal handler.
1877 @end ignore
1878
1879 The relocating allocation functions (@pxref{Relocating Allocator})
1880 are certainly not safe to use in a signal handler.
1881
1882 @item
1883 Any function that modifies @code{errno} is non-reentrant, but you can
1884 correct for this: in the handler, save the original value of
1885 @code{errno} and restore it before returning normally.  This prevents
1886 errors that occur within the signal handler from being confused with
1887 errors from system calls at the point the program is interrupted to run
1888 the handler.
1889
1890 This technique is generally applicable; if you want to call in a handler
1891 a function that modifies a particular object in memory, you can make
1892 this safe by saving and restoring that object.
1893
1894 @item
1895 Merely reading from a memory object is safe provided that you can deal
1896 with any of the values that might appear in the object at a time when
1897 the signal can be delivered.  Keep in mind that assignment to some data
1898 types requires more than one instruction, which means that the handler
1899 could run ``in the middle of'' an assignment to the variable if its type
1900 is not atomic.  @xref{Atomic Data Access}.
1901
1902 @item
1903 Merely writing into a memory object is safe as long as a sudden change
1904 in the value, at any time when the handler might run, will not disturb
1905 anything.
1906 @end itemize
1907
1908 @node Atomic Data Access
1909 @subsection Atomic Data Access and Signal Handling
1910
1911 Whether the data in your application concerns atoms, or mere text, you
1912 have to be careful about the fact that access to a single datum is not
1913 necessarily @dfn{atomic}.  This means that it can take more than one
1914 instruction to read or write a single object.  In such cases, a signal
1915 handler might in the middle of reading or writing the object.
1916
1917 There are three ways you can cope with this problem.  You can use data
1918 types that are always accessed atomically; you can carefully arrange
1919 that nothing untoward happens if an access is interrupted, or you can
1920 block all signals around any access that had better not be interrupted
1921 (@pxref{Blocking Signals}).
1922
1923 @menu
1924 * Non-atomic Example::          A program illustrating interrupted access.
1925 * Types: Atomic Types.          Data types that guarantee no interruption.
1926 * Usage: Atomic Usage.          Proving that interruption is harmless.
1927 @end menu
1928
1929 @node Non-atomic Example
1930 @subsubsection Problems with Non-Atomic Access
1931
1932 Here is an example which shows what can happen if a signal handler runs
1933 in the middle of modifying a variable.  (Interrupting the reading of a
1934 variable can also lead to paradoxical results, but here we only show
1935 writing.)
1936
1937 @smallexample
1938 #include <signal.h>
1939 #include <stdio.h>
1940
1941 struct two_words @{ int a, b; @} memory;
1942
1943 void
1944 handler(int signum)
1945 @{
1946    printf ("%d,%d\n", memory.a, memory.b);
1947    alarm (1);
1948 @}
1949
1950 @group
1951 int
1952 main (void)
1953 @{
1954    static struct two_words zeros = @{ 0, 0 @}, ones = @{ 1, 1 @};
1955    signal (SIGALRM, handler);
1956    memory = zeros;
1957    alarm (1);
1958    while (1)
1959      @{
1960        memory = zeros;
1961        memory = ones;
1962      @}
1963 @}
1964 @end group
1965 @end smallexample
1966
1967 This program fills @code{memory} with zeros, ones, zeros, ones,
1968 alternating forever; meanwhile, once per second, the alarm signal handler
1969 prints the current contents.  (Calling @code{printf} in the handler is
1970 safe in this program because it is certainly not being called outside
1971 the handler when the signal happens.)
1972
1973 Clearly, this program can print a pair of zeros or a pair of ones.  But
1974 that's not all it can do!  On most machines, it takes several
1975 instructions to store a new value in @code{memory}, and the value is
1976 stored one word at a time.  If the signal is delivered in between these
1977 instructions, the handler might find that @code{memory.a} is zero and
1978 @code{memory.b} is one (or vice versa).
1979
1980 On some machines it may be possible to store a new value in
1981 @code{memory} with just one instruction that cannot be interrupted.  On
1982 these machines, the handler will always print two zeros or two ones.
1983
1984 @node Atomic Types
1985 @subsubsection Atomic Types
1986
1987 To avoid uncertainty about interrupting access to a variable, you can
1988 use a particular data type for which access is always atomic:
1989 @code{sig_atomic_t}.  Reading and writing this data type is guaranteed
1990 to happen in a single instruction, so there's no way for a handler to
1991 run ``in the middle'' of an access.
1992
1993 The type @code{sig_atomic_t} is always an integer data type, but which
1994 one it is, and how many bits it contains, may vary from machine to
1995 machine.
1996
1997 @comment signal.h
1998 @comment ISO
1999 @deftp {Data Type} sig_atomic_t
2000 This is an integer data type.  Objects of this type are always accessed
2001 atomically.
2002 @end deftp
2003
2004 In practice, you can assume that @code{int} and other integer types no
2005 longer than @code{int} are atomic.  You can also assume that pointer
2006 types are atomic; that is very convenient.  Both of these are true on
2007 all of the machines that the GNU C library supports, and on all POSIX
2008 systems we know of.
2009 @c ??? This might fail on a 386 that uses 64-bit pointers.
2010
2011 @node Atomic Usage
2012 @subsubsection Atomic Usage Patterns
2013
2014 Certain patterns of access avoid any problem even if an access is
2015 interrupted.  For example, a flag which is set by the handler, and
2016 tested and cleared by the main program from time to time, is always safe
2017 even if access actually requires two instructions.  To show that this is
2018 so, we must consider each access that could be interrupted, and show
2019 that there is no problem if it is interrupted.
2020
2021 An interrupt in the middle of testing the flag is safe because either it's
2022 recognized to be nonzero, in which case the precise value doesn't
2023 matter, or it will be seen to be nonzero the next time it's tested.
2024
2025 An interrupt in the middle of clearing the flag is no problem because
2026 either the value ends up zero, which is what happens if a signal comes
2027 in just before the flag is cleared, or the value ends up nonzero, and
2028 subsequent events occur as if the signal had come in just after the flag
2029 was cleared.  As long as the code handles both of these cases properly,
2030 it can also handle a signal in the middle of clearing the flag.  (This
2031 is an example of the sort of reasoning you need to do to figure out
2032 whether non-atomic usage is safe.)
2033
2034 Sometimes you can insure uninterrupted access to one object by
2035 protecting its use with another object, perhaps one whose type
2036 guarantees atomicity.  @xref{Merged Signals}, for an example.
2037
2038 @node Interrupted Primitives
2039 @section Primitives Interrupted by Signals
2040
2041 A signal can arrive and be handled while an I/O primitive such as
2042 @code{open} or @code{read} is waiting for an I/O device.  If the signal
2043 handler returns, the system faces the question: what should happen next?
2044
2045 POSIX specifies one approach: make the primitive fail right away.  The
2046 error code for this kind of failure is @code{EINTR}.  This is flexible,
2047 but usually inconvenient.  Typically, POSIX applications that use signal
2048 handlers must check for @code{EINTR} after each library function that
2049 can return it, in order to try the call again.  Often programmers forget
2050 to check, which is a common source of error.
2051
2052 The GNU library provides a convenient way to retry a call after a
2053 temporary failure, with the macro @code{TEMP_FAILURE_RETRY}:
2054
2055 @comment unistd.h
2056 @comment GNU
2057 @defmac TEMP_FAILURE_RETRY (@var{expression})
2058 This macro evaluates @var{expression} once.  If it fails and reports
2059 error code @code{EINTR}, @code{TEMP_FAILURE_RETRY} evaluates it again,
2060 and over and over until the result is not a temporary failure.
2061
2062 The value returned by @code{TEMP_FAILURE_RETRY} is whatever value
2063 @var{expression} produced.
2064 @end defmac
2065
2066 BSD avoids @code{EINTR} entirely and provides a more convenient
2067 approach: to restart the interrupted primitive, instead of making it
2068 fail.  If you choose this approach, you need not be concerned with
2069 @code{EINTR}.
2070
2071 You can choose either approach with the GNU library.  If you use
2072 @code{sigaction} to establish a signal handler, you can specify how that
2073 handler should behave.  If you specify the @code{SA_RESTART} flag,
2074 return from that handler will resume a primitive; otherwise, return from
2075 that handler will cause @code{EINTR}.  @xref{Flags for Sigaction}.
2076
2077 Another way to specify the choice is with the @code{siginterrupt}
2078 function.  @xref{BSD Handler}.
2079
2080 @c !!! not true now about _BSD_SOURCE
2081 When you don't specify with @code{sigaction} or @code{siginterrupt} what
2082 a particular handler should do, it uses a default choice.  The default
2083 choice in the GNU library depends on the feature test macros you have
2084 defined.  If you define @code{_BSD_SOURCE} or @code{_GNU_SOURCE} before
2085 calling @code{signal}, the default is to resume primitives; otherwise,
2086 the default is to make them fail with @code{EINTR}.  (The library
2087 contains alternate versions of the @code{signal} function, and the
2088 feature test macros determine which one you really call.)  @xref{Feature
2089 Test Macros}.
2090 @cindex EINTR, and restarting interrupted primitives
2091 @cindex restarting interrupted primitives
2092 @cindex interrupting primitives
2093 @cindex primitives, interrupting
2094 @c !!! want to have @cindex system calls @i{see} primitives [no page #]
2095
2096 The description of each primitive affected by this issue
2097 lists @code{EINTR} among the error codes it can return.
2098
2099 There is one situation where resumption never happens no matter which
2100 choice you make: when a data-transfer function such as @code{read} or
2101 @code{write} is interrupted by a signal after transferring part of the
2102 data.  In this case, the function returns the number of bytes already
2103 transferred, indicating partial success.
2104
2105 This might at first appear to cause unreliable behavior on
2106 record-oriented devices (including datagram sockets; @pxref{Datagrams}),
2107 where splitting one @code{read} or @code{write} into two would read or
2108 write two records.  Actually, there is no problem, because interruption
2109 after a partial transfer cannot happen on such devices; they always
2110 transfer an entire record in one burst, with no waiting once data
2111 transfer has started.
2112
2113 @node Generating Signals
2114 @section Generating Signals
2115 @cindex sending signals
2116 @cindex raising signals
2117 @cindex signals, generating
2118
2119 Besides signals that are generated as a result of a hardware trap or
2120 interrupt, your program can explicitly send signals to itself or to
2121 another process.
2122
2123 @menu
2124 * Signaling Yourself::          A process can send a signal to itself.
2125 * Signaling Another Process::   Send a signal to another process.
2126 * Permission for kill::         Permission for using @code{kill}.
2127 * Kill Example::                Using @code{kill} for Communication.
2128 @end menu
2129
2130 @node Signaling Yourself
2131 @subsection Signaling Yourself
2132
2133 A process can send itself a signal with the @code{raise} function.  This
2134 function is declared in @file{signal.h}.
2135 @pindex signal.h
2136
2137 @comment signal.h
2138 @comment ISO
2139 @deftypefun int raise (int @var{signum})
2140 The @code{raise} function sends the signal @var{signum} to the calling
2141 process.  It returns zero if successful and a nonzero value if it fails.
2142 About the only reason for failure would be if the value of @var{signum}
2143 is invalid.
2144 @end deftypefun
2145
2146 @comment signal.h
2147 @comment SVID
2148 @deftypefun int gsignal (int @var{signum})
2149 The @code{gsignal} function does the same thing as @code{raise}; it is
2150 provided only for compatibility with SVID.
2151 @end deftypefun
2152
2153 One convenient use for @code{raise} is to reproduce the default behavior
2154 of a signal that you have trapped.  For instance, suppose a user of your
2155 program types the SUSP character (usually @kbd{C-z}; @pxref{Special
2156 Characters}) to send it an interactive stop stop signal
2157 (@code{SIGTSTP}), and you want to clean up some internal data buffers
2158 before stopping.  You might set this up like this:
2159
2160 @comment RMS suggested getting rid of the handler for SIGCONT in this function.
2161 @comment But that would require that the handler for SIGTSTP unblock the
2162 @comment signal before doing the call to raise.  We haven't covered that
2163 @comment topic yet, and I don't want to distract from the main point of
2164 @comment the example with a digression to explain what is going on.  As
2165 @comment the example is written, the signal that is raise'd will be delivered
2166 @comment as soon as the SIGTSTP handler returns, which is fine.
2167
2168 @smallexample
2169 #include <signal.h>
2170
2171 /* @r{When a stop signal arrives, set the action back to the default
2172    and then resend the signal after doing cleanup actions.} */
2173
2174 void
2175 tstp_handler (int sig)
2176 @{
2177   signal (SIGTSTP, SIG_DFL);
2178   /* @r{Do cleanup actions here.} */
2179   @dots{}
2180   raise (SIGTSTP);
2181 @}
2182
2183 /* @r{When the process is continued again, restore the signal handler.} */
2184
2185 void
2186 cont_handler (int sig)
2187 @{
2188   signal (SIGCONT, cont_handler);
2189   signal (SIGTSTP, tstp_handler);
2190 @}
2191
2192 @group
2193 /* @r{Enable both handlers during program initialization.} */
2194
2195 int
2196 main (void)
2197 @{
2198   signal (SIGCONT, cont_handler);
2199   signal (SIGTSTP, tstp_handler);
2200   @dots{}
2201 @}
2202 @end group
2203 @end smallexample
2204
2205 @strong{Portability note:} @code{raise} was invented by the @w{ISO C}
2206 committee.  Older systems may not support it, so using @code{kill} may
2207 be more portable.  @xref{Signaling Another Process}.
2208
2209 @node Signaling Another Process
2210 @subsection Signaling Another Process
2211
2212 @cindex killing a process
2213 The @code{kill} function can be used to send a signal to another process.
2214 In spite of its name, it can be used for a lot of things other than
2215 causing a process to terminate.  Some examples of situations where you
2216 might want to send signals between processes are:
2217
2218 @itemize @bullet
2219 @item
2220 A parent process starts a child to perform a task---perhaps having the
2221 child running an infinite loop---and then terminates the child when the
2222 task is no longer needed.
2223
2224 @item
2225 A process executes as part of a group, and needs to terminate or notify
2226 the other processes in the group when an error or other event occurs.
2227
2228 @item
2229 Two processes need to synchronize while working together.
2230 @end itemize
2231
2232 This section assumes that you know a little bit about how processes
2233 work.  For more information on this subject, see @ref{Processes}.
2234
2235 The @code{kill} function is declared in @file{signal.h}.
2236 @pindex signal.h
2237
2238 @comment signal.h
2239 @comment POSIX.1
2240 @deftypefun int kill (pid_t @var{pid}, int @var{signum})
2241 The @code{kill} function sends the signal @var{signum} to the process
2242 or process group specified by @var{pid}.  Besides the signals listed in
2243 @ref{Standard Signals}, @var{signum} can also have a value of zero to
2244 check the validity of the @var{pid}.
2245
2246 The @var{pid} specifies the process or process group to receive the
2247 signal:
2248
2249 @table @code
2250 @item @var{pid} > 0
2251 The process whose identifier is @var{pid}.
2252
2253 @item @var{pid} == 0
2254 All processes in the same process group as the sender.
2255
2256 @item @var{pid} < -1
2257 The process group whose identifier is @minus{}@var{pid}.
2258
2259 @item @var{pid} == -1
2260 If the process is privileged, send the signal to all processes except
2261 for some special system processes.  Otherwise, send the signal to all
2262 processes with the same effective user ID.
2263 @end table
2264
2265 A process can send a signal @var{signum} to itself with a call like
2266 @w{@code{kill (getpid(), @var{signum})}}.  If @code{kill} is used by a
2267 process to send a signal to itself, and the signal is not blocked, then
2268 @code{kill} delivers at least one signal (which might be some other
2269 pending unblocked signal instead of the signal @var{signum}) to that
2270 process before it returns.
2271
2272 The return value from @code{kill} is zero if the signal can be sent
2273 successfully.  Otherwise, no signal is sent, and a value of @code{-1} is
2274 returned.  If @var{pid} specifies sending a signal to several processes,
2275 @code{kill} succeeds if it can send the signal to at least one of them.
2276 There's no way you can tell which of the processes got the signal
2277 or whether all of them did.
2278
2279 The following @code{errno} error conditions are defined for this function:
2280
2281 @table @code
2282 @item EINVAL
2283 The @var{signum} argument is an invalid or unsupported number.
2284
2285 @item EPERM
2286 You do not have the privilege to send a signal to the process or any of
2287 the processes in the process group named by @var{pid}.
2288
2289 @item ESCRH
2290 The @var{pid} argument does not refer to an existing process or group.
2291 @end table
2292 @end deftypefun
2293
2294 @comment signal.h
2295 @comment BSD
2296 @deftypefun int killpg (int @var{pgid}, int @var{signum})
2297 This is similar to @code{kill}, but sends signal @var{signum} to the
2298 process group @var{pgid}.  This function is provided for compatibility
2299 with BSD; using @code{kill} to do this is more portable.
2300 @end deftypefun
2301
2302 As a simple example of @code{kill}, the call @w{@code{kill (getpid (),
2303 @var{sig})}} has the same effect as @w{@code{raise (@var{sig})}}.
2304
2305 @node Permission for kill
2306 @subsection Permission for using @code{kill}
2307
2308 There are restrictions that prevent you from using @code{kill} to send
2309 signals to any random process.  These are intended to prevent antisocial
2310 behavior such as arbitrarily killing off processes belonging to another
2311 user.  In typical use, @code{kill} is used to pass signals between
2312 parent, child, and sibling processes, and in these situations you
2313 normally do have permission to send signals.  The only common exception
2314 is when you run a setuid program in a child process; if the program
2315 changes its real UID as well as its effective UID, you may not have
2316 permission to send a signal.  The @code{su} program does this.
2317
2318 Whether a process has permission to send a signal to another process
2319 is determined by the user IDs of the two processes.  This concept is
2320 discussed in detail in @ref{Process Persona}.
2321
2322 Generally, for a process to be able to send a signal to another process,
2323 either the sending process must belong to a privileged user (like
2324 @samp{root}), or the real or effective user ID of the sending process
2325 must match the real or effective user ID of the receiving process.  If
2326 the receiving process has changed its effective user ID from the
2327 set-user-ID mode bit on its process image file, then the owner of the
2328 process image file is used in place of its current effective user ID.
2329 In some implementations, a parent process might be able to send signals
2330 to a child process even if the user ID's don't match, and other
2331 implementations might enforce other restrictions.
2332
2333 The @code{SIGCONT} signal is a special case.  It can be sent if the
2334 sender is part of the same session as the receiver, regardless of
2335 user IDs.
2336
2337 @node Kill Example
2338 @subsection Using @code{kill} for Communication
2339 @cindex interprocess communication, with signals
2340 Here is a longer example showing how signals can be used for
2341 interprocess communication.  This is what the @code{SIGUSR1} and
2342 @code{SIGUSR2} signals are provided for.  Since these signals are fatal
2343 by default, the process that is supposed to receive them must trap them
2344 through @code{signal} or @code{sigaction}.
2345
2346 In this example, a parent process forks a child process and then waits
2347 for the child to complete its initialization.  The child process tells
2348 the parent when it is ready by sending it a @code{SIGUSR1} signal, using
2349 the @code{kill} function.
2350
2351 @smallexample
2352 @include sigusr.c.texi
2353 @end smallexample
2354
2355 This example uses a busy wait, which is bad, because it wastes CPU
2356 cycles that other programs could otherwise use.  It is better to ask the
2357 system to wait until the signal arrives.  See the example in
2358 @ref{Waiting for a Signal}.
2359
2360 @node Blocking Signals
2361 @section Blocking Signals
2362 @cindex blocking signals
2363
2364 Blocking a signal means telling the operating system to hold it and
2365 deliver it later.  Generally, a program does not block signals
2366 indefinitely---it might as well ignore them by setting their actions to
2367 @code{SIG_IGN}.  But it is useful to block signals briefly, to prevent
2368 them from interrupting sensitive operations.  For instance:
2369
2370 @itemize @bullet
2371 @item
2372 You can use the @code{sigprocmask} function to block signals while you
2373 modify global variables that are also modified by the handlers for these
2374 signals.
2375
2376 @item
2377 You can set @code{sa_mask} in your @code{sigaction} call to block
2378 certain signals while a particular signal handler runs.  This way, the
2379 signal handler can run without being interrupted itself by signals.
2380 @end itemize
2381
2382 @menu
2383 * Why Block::                           The purpose of blocking signals.
2384 * Signal Sets::                         How to specify which signals to
2385                                          block.
2386 * Process Signal Mask::                 Blocking delivery of signals to your
2387                                          process during normal execution.
2388 * Testing for Delivery::                Blocking to Test for Delivery of
2389                                          a Signal.
2390 * Blocking for Handler::                Blocking additional signals while a
2391                                          handler is being run.
2392 * Checking for Pending Signals::        Checking for Pending Signals
2393 * Remembering a Signal::                How you can get almost the same
2394                                          effect as blocking a signal, by
2395                                          handling it and setting a flag
2396                                          to be tested later.
2397 @end menu
2398
2399 @node Why Block
2400 @subsection Why Blocking Signals is Useful
2401
2402 Temporary blocking of signals with @code{sigprocmask} gives you a way to
2403 prevent interrupts during critical parts of your code.  If signals
2404 arrive in that part of the program, they are delivered later, after you
2405 unblock them.
2406
2407 One example where this is useful is for sharing data between a signal
2408 handler and the rest of the program.  If the type of the data is not
2409 @code{sig_atomic_t} (@pxref{Atomic Data Access}), then the signal
2410 handler could run when the rest of the program has only half finished
2411 reading or writing the data.  This would lead to confusing consequences.
2412
2413 To make the program reliable, you can prevent the signal handler from
2414 running while the rest of the program is examining or modifying that
2415 data---by blocking the appropriate signal around the parts of the
2416 program that touch the data.
2417
2418 Blocking signals is also necessary when you want to perform a certain
2419 action only if a signal has not arrived.  Suppose that the handler for
2420 the signal sets a flag of type @code{sig_atomic_t}; you would like to
2421 test the flag and perform the action if the flag is not set.  This is
2422 unreliable.  Suppose the signal is delivered immediately after you test
2423 the flag, but before the consequent action: then the program will
2424 perform the action even though the signal has arrived.
2425
2426 The only way to test reliably for whether a signal has yet arrived is to
2427 test while the signal is blocked.
2428
2429 @node Signal Sets
2430 @subsection Signal Sets
2431
2432 All of the signal blocking functions use a data structure called a
2433 @dfn{signal set} to specify what signals are affected.  Thus, every
2434 activity involves two stages: creating the signal set, and then passing
2435 it as an argument to a library function.
2436 @cindex signal set
2437
2438 These facilities are declared in the header file @file{signal.h}.
2439 @pindex signal.h
2440
2441 @comment signal.h
2442 @comment POSIX.1
2443 @deftp {Data Type} sigset_t
2444 The @code{sigset_t} data type is used to represent a signal set.
2445 Internally, it may be implemented as either an integer or structure
2446 type.
2447
2448 For portability, use only the functions described in this section to
2449 initialize, change, and retrieve information from @code{sigset_t}
2450 objects---don't try to manipulate them directly.
2451 @end deftp
2452
2453 There are two ways to initialize a signal set.  You can initially
2454 specify it to be empty with @code{sigemptyset} and then add specified
2455 signals individually.  Or you can specify it to be full with
2456 @code{sigfillset} and then delete specified signals individually.
2457
2458 You must always initialize the signal set with one of these two
2459 functions before using it in any other way.  Don't try to set all the
2460 signals explicitly because the @code{sigset_t} object might include some
2461 other information (like a version field) that needs to be initialized as
2462 well.  (In addition, it's not wise to put into your program an
2463 assumption that the system has no signals aside from the ones you know
2464 about.)
2465
2466 @comment signal.h
2467 @comment POSIX.1
2468 @deftypefun int sigemptyset (sigset_t *@var{set})
2469 This function initializes the signal set @var{set} to exclude all of the
2470 defined signals.  It always returns @code{0}.
2471 @end deftypefun
2472
2473 @comment signal.h
2474 @comment POSIX.1
2475 @deftypefun int sigfillset (sigset_t *@var{set})
2476 This function initializes the signal set @var{set} to include
2477 all of the defined signals.  Again, the return value is @code{0}.
2478 @end deftypefun
2479
2480 @comment signal.h
2481 @comment POSIX.1
2482 @deftypefun int sigaddset (sigset_t *@var{set}, int @var{signum})
2483 This function adds the signal @var{signum} to the signal set @var{set}.
2484 All @code{sigaddset} does is modify @var{set}; it does not block or
2485 unblock any signals.
2486
2487 The return value is @code{0} on success and @code{-1} on failure.
2488 The following @code{errno} error condition is defined for this function:
2489
2490 @table @code
2491 @item EINVAL
2492 The @var{signum} argument doesn't specify a valid signal.
2493 @end table
2494 @end deftypefun
2495
2496 @comment signal.h
2497 @comment POSIX.1
2498 @deftypefun int sigdelset (sigset_t *@var{set}, int @var{signum})
2499 This function removes the signal @var{signum} from the signal set
2500 @var{set}.  All @code{sigdelset} does is modify @var{set}; it does not
2501 block or unblock any signals.  The return value and error conditions are
2502 the same as for @code{sigaddset}.
2503 @end deftypefun
2504
2505 Finally, there is a function to test what signals are in a signal set:
2506
2507 @comment signal.h
2508 @comment POSIX.1
2509 @deftypefun int sigismember (const sigset_t *@var{set}, int @var{signum})
2510 The @code{sigismember} function tests whether the signal @var{signum} is
2511 a member of the signal set @var{set}.  It returns @code{1} if the signal
2512 is in the set, @code{0} if not, and @code{-1} if there is an error.
2513
2514 The following @code{errno} error condition is defined for this function:
2515
2516 @table @code
2517 @item EINVAL
2518 The @var{signum} argument doesn't specify a valid signal.
2519 @end table
2520 @end deftypefun
2521
2522 @node Process Signal Mask
2523 @subsection Process Signal Mask
2524 @cindex signal mask
2525 @cindex process signal mask
2526
2527 The collection of signals that are currently blocked is called the
2528 @dfn{signal mask}.  Each process has its own signal mask.  When you
2529 create a new process (@pxref{Creating a Process}), it inherits its
2530 parent's mask.  You can block or unblock signals with total flexibility
2531 by modifying the signal mask.
2532
2533 The prototype for the @code{sigprocmask} function is in @file{signal.h}.
2534 @pindex signal.h
2535
2536 @comment signal.h
2537 @comment POSIX.1
2538 @deftypefun int sigprocmask (int @var{how}, const sigset_t *@var{set}, sigset_t *@var{oldset})
2539 The @code{sigprocmask} function is used to examine or change the calling
2540 process's signal mask.  The @var{how} argument determines how the signal
2541 mask is changed, and must be one of the following values:
2542
2543 @table @code
2544 @comment signal.h
2545 @comment POSIX.1
2546 @vindex SIG_BLOCK
2547 @item SIG_BLOCK
2548 Block the signals in @code{set}---add them to the existing mask.  In
2549 other words, the new mask is the union of the existing mask and
2550 @var{set}.
2551
2552 @comment signal.h
2553 @comment POSIX.1
2554 @vindex SIG_UNBLOCK
2555 @item SIG_UNBLOCK
2556 Unblock the signals in @var{set}---remove them from the existing mask.
2557
2558 @comment signal.h
2559 @comment POSIX.1
2560 @vindex SIG_SETMASK
2561 @item SIG_SETMASK
2562 Use @var{set} for the mask; ignore the previous value of the mask.
2563 @end table
2564
2565 The last argument, @var{oldset}, is used to return information about the
2566 old process signal mask.  If you just want to change the mask without
2567 looking at it, pass a null pointer as the @var{oldset} argument.
2568 Similarly, if you want to know what's in the mask without changing it,
2569 pass a null pointer for @var{set} (in this case the @var{how} argument
2570 is not significant).  The @var{oldset} argument is often used to
2571 remember the previous signal mask in order to restore it later.  (Since
2572 the signal mask is inherited over @code{fork} and @code{exec} calls, you
2573 can't predict what its contents are when your program starts running.)
2574
2575 If invoking @code{sigprocmask} causes any pending signals to be
2576 unblocked, at least one of those signals is delivered to the process
2577 before @code{sigprocmask} returns.  The order in which pending signals
2578 are delivered is not specified, but you can control the order explicitly
2579 by making multiple @code{sigprocmask} calls to unblock various signals
2580 one at a time.
2581
2582 The @code{sigprocmask} function returns @code{0} if successful, and @code{-1}
2583 to indicate an error.  The following @code{errno} error conditions are
2584 defined for this function:
2585
2586 @table @code
2587 @item EINVAL
2588 The @var{how} argument is invalid.
2589 @end table
2590
2591 You can't block the @code{SIGKILL} and @code{SIGSTOP} signals, but
2592 if the signal set includes these, @code{sigprocmask} just ignores
2593 them instead of returning an error status.
2594
2595 Remember, too, that blocking program error signals such as @code{SIGFPE}
2596 leads to undesirable results for signals generated by an actual program
2597 error (as opposed to signals sent with @code{raise} or @code{kill}).
2598 This is because your program may be too broken to be able to continue
2599 executing to a point where the signal is unblocked again.
2600 @xref{Program Error Signals}.
2601 @end deftypefun
2602
2603 @node Testing for Delivery
2604 @subsection Blocking to Test for Delivery of a Signal
2605
2606 Now for a simple example.  Suppose you establish a handler for
2607 @code{SIGALRM} signals that sets a flag whenever a signal arrives, and
2608 your main program checks this flag from time to time and then resets it.
2609 You can prevent additional @code{SIGALRM} signals from arriving in the
2610 meantime by wrapping the critical part of the code with calls to
2611 @code{sigprocmask}, like this:
2612
2613 @smallexample
2614 /* @r{This variable is set by the SIGALRM signal handler.} */
2615 volatile sig_atomic_t flag = 0;
2616
2617 int
2618 main (void)
2619 @{
2620   sigset_t block_alarm;
2621
2622   @dots{}
2623
2624   /* @r{Initialize the signal mask.} */
2625   sigemptyset (&block_alarm);
2626   sigaddset (&block_alarm, SIGALRM);
2627
2628 @group
2629   while (1)
2630     @{
2631       /* @r{Check if a signal has arrived; if so, reset the flag.} */
2632       sigprocmask (SIG_BLOCK, &block_alarm, NULL);
2633       if (flag)
2634         @{
2635           @var{actions-if-not-arrived}
2636           flag = 0;
2637         @}
2638       sigprocmask (SIG_UNBLOCK, &block_alarm, NULL);
2639
2640       @dots{}
2641     @}
2642 @}
2643 @end group
2644 @end smallexample
2645
2646 @node Blocking for Handler
2647 @subsection Blocking Signals for a Handler
2648 @cindex blocking signals, in a handler
2649
2650 When a signal handler is invoked, you usually want it to be able to
2651 finish without being interrupted by another signal.  From the moment the
2652 handler starts until the moment it finishes, you must block signals that
2653 might confuse it or corrupt its data.
2654
2655 When a handler function is invoked on a signal, that signal is
2656 automatically blocked (in addition to any other signals that are already
2657 in the process's signal mask) during the time the handler is running.
2658 If you set up a handler for @code{SIGTSTP}, for instance, then the
2659 arrival of that signal forces further @code{SIGTSTP} signals to wait
2660 during the execution of the handler.
2661
2662 However, by default, other kinds of signals are not blocked; they can
2663 arrive during handler execution.
2664
2665 The reliable way to block other kinds of signals during the execution of
2666 the handler is to use the @code{sa_mask} member of the @code{sigaction}
2667 structure.
2668
2669 Here is an example:
2670
2671 @smallexample
2672 #include <signal.h>
2673 #include <stddef.h>
2674
2675 void catch_stop ();
2676
2677 void
2678 install_handler (void)
2679 @{
2680   struct sigaction setup_action;
2681   sigset_t block_mask;
2682
2683   sigemptyset (&block_mask);
2684   /* @r{Block other terminal-generated signals while handler runs.} */
2685   sigaddset (&block_mask, SIGINT);
2686   sigaddset (&block_mask, SIGQUIT);
2687   setup_action.sa_handler = catch_stop;
2688   setup_action.sa_mask = block_mask;
2689   setup_action.sa_flags = 0;
2690   sigaction (SIGTSTP, &setup_action, NULL);
2691 @}
2692 @end smallexample
2693
2694 This is more reliable than blocking the other signals explicitly in the
2695 code for the handler.  If you block signals explicitly in the handler,
2696 you can't avoid at least a short interval at the beginning of the
2697 handler where they are not yet blocked.
2698
2699 You cannot remove signals from the process's current mask using this
2700 mechanism.  However, you can make calls to @code{sigprocmask} within
2701 your handler to block or unblock signals as you wish.
2702
2703 In any case, when the handler returns, the system restores the mask that
2704 was in place before the handler was entered.  If any signals that become
2705 unblocked by this restoration are pending, the process will receive
2706 those signals immediately, before returning to the code that was
2707 interrupted.
2708
2709 @node Checking for Pending Signals
2710 @subsection Checking for Pending Signals
2711 @cindex pending signals, checking for
2712 @cindex blocked signals, checking for
2713 @cindex checking for pending signals
2714
2715 You can find out which signals are pending at any time by calling
2716 @code{sigpending}.  This function is declared in @file{signal.h}.
2717 @pindex signal.h
2718
2719 @comment signal.h
2720 @comment POSIX.1
2721 @deftypefun int sigpending (sigset_t *@var{set})
2722 The @code{sigpending} function stores information about pending signals
2723 in @var{set}.  If there is a pending signal that is blocked from
2724 delivery, then that signal is a member of the returned set.  (You can
2725 test whether a particular signal is a member of this set using
2726 @code{sigismember}; see @ref{Signal Sets}.)
2727
2728 The return value is @code{0} if successful, and @code{-1} on failure.
2729 @end deftypefun
2730
2731 Testing whether a signal is pending is not often useful.  Testing when
2732 that signal is not blocked is almost certainly bad design.
2733
2734 Here is an example.
2735
2736 @smallexample
2737 #include <signal.h>
2738 #include <stddef.h>
2739
2740 sigset_t base_mask, waiting_mask;
2741
2742 sigemptyset (&base_mask);
2743 sigaddset (&base_mask, SIGINT);
2744 sigaddset (&base_mask, SIGTSTP);
2745
2746 /* @r{Block user interrupts while doing other processing.} */
2747 sigprocmask (SIG_SETMASK, &base_mask, NULL);
2748 @dots{}
2749
2750 /* @r{After a while, check to see whether any signals are pending.} */
2751 sigpending (&waiting_mask);
2752 if (sigismember (&waiting_mask, SIGINT)) @{
2753   /* @r{User has tried to kill the process.} */
2754 @}
2755 else if (sigismember (&waiting_mask, SIGTSTP)) @{
2756   /* @r{User has tried to stop the process.} */
2757 @}
2758 @end smallexample
2759
2760 Remember that if there is a particular signal pending for your process,
2761 additional signals of that same type that arrive in the meantime might
2762 be discarded.  For example, if a @code{SIGINT} signal is pending when
2763 another @code{SIGINT} signal arrives, your program will probably only
2764 see one of them when you unblock this signal.
2765
2766 @strong{Portability Note:} The @code{sigpending} function is new in
2767 POSIX.1.  Older systems have no equivalent facility.
2768
2769 @node Remembering a Signal
2770 @subsection Remembering a Signal to Act On Later
2771
2772 Instead of blocking a signal using the library facilities, you can get
2773 almost the same results by making the handler set a flag to be tested
2774 later, when you ``unblock''.  Here is an example:
2775
2776 @smallexample
2777 /* @r{If this flag is nonzero, don't handle the signal right away.} */
2778 volatile sig_atomic_t signal_pending;
2779
2780 /* @r{This is nonzero if a signal arrived and was not handled.} */
2781 volatile sig_atomic_t defer_signal;
2782
2783 void
2784 handler (int signum)
2785 @{
2786   if (defer_signal)
2787     signal_pending = signum;
2788   else
2789     @dots{} /* @r{``Really'' handle the signal.} */
2790 @}
2791
2792 @dots{}
2793
2794 void
2795 update_mumble (int frob)
2796 @{
2797   /* @r{Prevent signals from having immediate effect.} */
2798   defer_signal++;
2799   /* @r{Now update @code{mumble}, without worrying about interruption.} */
2800   mumble.a = 1;
2801   mumble.b = hack ();
2802   mumble.c = frob;
2803   /* @r{We have updated @code{mumble}.  Handle any signal that came in.} */
2804   defer_signal--;
2805   if (defer_signal == 0 && signal_pending != 0)
2806     raise (signal_pending);
2807 @}
2808 @end smallexample
2809
2810 Note how the particular signal that arrives is stored in
2811 @code{signal_pending}.  That way, we can handle several types of
2812 inconvenient signals with the same mechanism.
2813
2814 We increment and decrement @code{defer_signal} so that nested critical
2815 sections will work properly; thus, if @code{update_mumble} were called
2816 with @code{signal_pending} already nonzero, signals would be deferred
2817 not only within @code{update_mumble}, but also within the caller.  This
2818 is also why we do not check @code{signal_pending} if @code{defer_signal}
2819 is still nonzero.
2820
2821 The incrementing and decrementing of @code{defer_signal} require more
2822 than one instruction; it is possible for a signal to happen in the
2823 middle.  But that does not cause any problem.  If the signal happens
2824 early enough to see the value from before the increment or decrement,
2825 that is equivalent to a signal which came before the beginning of the
2826 increment or decrement, which is a case that works properly.
2827
2828 It is absolutely vital to decrement @code{defer_signal} before testing
2829 @code{signal_pending}, because this avoids a subtle bug.  If we did
2830 these things in the other order, like this,
2831
2832 @smallexample
2833   if (defer_signal == 1 && signal_pending != 0)
2834     raise (signal_pending);
2835   defer_signal--;
2836 @end smallexample
2837
2838 @noindent
2839 then a signal arriving in between the @code{if} statement and the decrement
2840 would be effectively ``lost'' for an indefinite amount of time.  The
2841 handler would merely set @code{defer_signal}, but the program having
2842 already tested this variable, it would not test the variable again.
2843
2844 @cindex timing error in signal handling
2845 Bugs like these are called @dfn{timing errors}.  They are especially bad
2846 because they happen only rarely and are nearly impossible to reproduce.
2847 You can't expect to find them with a debugger as you would find a
2848 reproducible bug.  So it is worth being especially careful to avoid
2849 them.
2850
2851 (You would not be tempted to write the code in this order, given the use
2852 of @code{defer_signal} as a counter which must be tested along with
2853 @code{signal_pending}.  After all, testing for zero is cleaner than
2854 testing for one.  But if you did not use @code{defer_signal} as a
2855 counter, and gave it values of zero and one only, then either order
2856 might seem equally simple.  This is a further advantage of using a
2857 counter for @code{defer_signal}: it will reduce the chance you will
2858 write the code in the wrong order and create a subtle bug.)
2859
2860 @node Waiting for a Signal
2861 @section Waiting for a Signal
2862 @cindex waiting for a signal
2863 @cindex @code{pause} function
2864
2865 If your program is driven by external events, or uses signals for
2866 synchronization, then when it has nothing to do it should probably wait
2867 until a signal arrives.
2868
2869 @menu
2870 * Using Pause::                 The simple way, using @code{pause}.
2871 * Pause Problems::              Why the simple way is often not very good.
2872 * Sigsuspend::                  Reliably waiting for a specific signal.
2873 @end menu
2874
2875 @node Using Pause
2876 @subsection Using @code{pause}
2877
2878 The simple way to wait until a signal arrives is to call @code{pause}.
2879 Please read about its disadvantages, in the following section, before
2880 you use it.
2881
2882 @comment unistd.h
2883 @comment POSIX.1
2884 @deftypefun int pause ()
2885 The @code{pause} function suspends program execution until a signal
2886 arrives whose action is either to execute a handler function, or to
2887 terminate the process.
2888
2889 If the signal causes a handler function to be executed, then
2890 @code{pause} returns.  This is considered an unsuccessful return (since
2891 ``successful'' behavior would be to suspend the program forever), so the
2892 return value is @code{-1}.  Even if you specify that other primitives
2893 should resume when a system handler returns (@pxref{Interrupted
2894 Primitives}), this has no effect on @code{pause}; it always fails when a
2895 signal is handled.
2896
2897 The following @code{errno} error conditions are defined for this function:
2898
2899 @table @code
2900 @item EINTR
2901 The function was interrupted by delivery of a signal.
2902 @end table
2903
2904 If the signal causes program termination, @code{pause} doesn't return
2905 (obviously).
2906
2907 The @code{pause} function is declared in  @file{unistd.h}.
2908 @end deftypefun
2909
2910 @node Pause Problems
2911 @subsection Problems with @code{pause}
2912
2913 The simplicity of @code{pause} can conceal serious timing errors that
2914 can make a program hang mysteriously.
2915
2916 It is safe to use @code{pause} if the real work of your program is done
2917 by the signal handlers themselves, and the ``main program'' does nothing
2918 but call @code{pause}.  Each time a signal is delivered, the handler
2919 will do the next batch of work that is to be done, and then return, so
2920 that the main loop of the program can call @code{pause} again.
2921
2922 You can't safely use @code{pause} to wait until one more signal arrives,
2923 and then resume real work.  Even if you arrange for the signal handler
2924 to cooperate by setting a flag, you still can't use @code{pause}
2925 reliably.  Here is an example of this problem:
2926
2927 @smallexample
2928 /* @r{@code{usr_interrupt} is set by the signal handler.}  */
2929 if (!usr_interrupt)
2930   pause ();
2931
2932 /* @r{Do work once the signal arrives.}  */
2933 @dots{}
2934 @end smallexample
2935
2936 @noindent
2937 This has a bug: the signal could arrive after the variable
2938 @code{usr_interrupt} is checked, but before the call to @code{pause}.
2939 If no further signals arrive, the process would never wake up again.
2940
2941 You can put an upper limit on the excess waiting by using @code{sleep}
2942 in a loop, instead of using @code{pause}.  (@xref{Sleeping}, for more
2943 about @code{sleep}.)  Here is what this looks like:
2944
2945 @smallexample
2946 /* @r{@code{usr_interrupt} is set by the signal handler.}
2947 while (!usr_interrupt)
2948   sleep (1);
2949
2950 /* @r{Do work once the signal arrives.}  */
2951 @dots{}
2952 @end smallexample
2953
2954 For some purposes, that is good enough.  But with a little more
2955 complexity, you can wait reliably until a particular signal handler is
2956 run, using @code{sigsuspend}.
2957 @ifinfo
2958 @xref{Sigsuspend}.
2959 @end ifinfo
2960
2961 @node Sigsuspend
2962 @subsection Using @code{sigsuspend}
2963
2964 The clean and reliable way to wait for a signal to arrive is to block it
2965 and then use @code{sigsuspend}.  By using @code{sigsuspend} in a loop,
2966 you can wait for certain kinds of signals, while letting other kinds of
2967 signals be handled by their handlers.
2968
2969 @comment signal.h
2970 @comment POSIX.1
2971 @deftypefun int sigsuspend (const sigset_t *@var{set})
2972 This function replaces the process's signal mask with @var{set} and then
2973 suspends the process until a signal is delivered whose action is either
2974 to terminate the process or invoke a signal handling function.  In other
2975 words, the program is effectively suspended until one of the signals that
2976 is not a member of @var{set} arrives.
2977
2978 If the process is woken up by deliver of a signal that invokes a handler
2979 function, and the handler function returns, then @code{sigsuspend} also
2980 returns.
2981
2982 The mask remains @var{set} only as long as @code{sigsuspend} is waiting.
2983 The function @code{sigsuspend} always restores the previous signal mask
2984 when it returns.
2985
2986 The return value and error conditions are the same as for @code{pause}.
2987 @end deftypefun
2988
2989 With @code{sigsuspend}, you can replace the @code{pause} or @code{sleep}
2990 loop in the previous section with something completely reliable:
2991
2992 @smallexample
2993 sigset_t mask, oldmask;
2994
2995 @dots{}
2996
2997 /* @r{Set up the mask of signals to temporarily block.} */
2998 sigemptyset (&mask);
2999 sigaddset (&mask, SIGUSR1);
3000
3001 @dots{}
3002
3003 /* @r{Wait for a signal to arrive.} */
3004 sigprocmask (SIG_BLOCK, &mask, &oldmask);
3005 while (!usr_interrupt)
3006   sigsuspend (&oldmask);
3007 sigprocmask (SIG_UNBLOCK, &mask, NULL);
3008 @end smallexample
3009
3010 This last piece of code is a little tricky.  The key point to remember
3011 here is that when @code{sigsuspend} returns, it resets the process's
3012 signal mask to the original value, the value from before the call to
3013 @code{sigsuspend}---in this case, the @code{SIGUSR1} signal is once
3014 again blocked.  The second call to @code{sigprocmask} is
3015 necessary to explicitly unblock this signal.
3016
3017 One other point: you may be wondering why the @code{while} loop is
3018 necessary at all, since the program is apparently only waiting for one
3019 @code{SIGUSR1} signal.  The answer is that the mask passed to
3020 @code{sigsuspend} permits the process to be woken up by the delivery of
3021 other kinds of signals, as well---for example, job control signals.  If
3022 the process is woken up by a signal that doesn't set
3023 @code{usr_interrupt}, it just suspends itself again until the ``right''
3024 kind of signal eventually arrives.
3025
3026 This technique takes a few more lines of preparation, but that is needed
3027 just once for each kind of wait criterion you want to use.  The code
3028 that actually waits is just four lines.
3029
3030 @node Signal Stack
3031 @section Using a Separate Signal Stack
3032
3033 A signal stack is a special area of memory to be used as the execution
3034 stack during signal handlers.  It should be fairly large, to avoid any
3035 danger that it will overflow in turn; the macro @code{SIGSTKSZ} is
3036 defined to a canonical size for signal stacks.  You can use
3037 @code{malloc} to allocate the space for the stack.  Then call
3038 @code{sigaltstack} or @code{sigstack} to tell the system to use that
3039 space for the signal stack.
3040
3041 You don't need to write signal handlers differently in order to use a
3042 signal stack.  Switching from one stack to the other happens
3043 automatically.  (Some non-GNU debuggers on some machines may get
3044 confused if you examine a stack trace while a handler that uses the
3045 signal stack is running.)
3046
3047 There are two interfaces for telling the system to use a separate signal
3048 stack.  @code{sigstack} is the older interface, which comes from 4.2
3049 BSD.  @code{sigaltstack} is the newer interface, and comes from 4.4
3050 BSD.  The @code{sigaltstack} interface has the advantage that it does
3051 not require your program to know which direction the stack grows, which
3052 depends on the specific machine and operating system.
3053
3054 @comment signal.h
3055 @comment BSD
3056 @deftp {Data Type} {struct sigaltstack}
3057 This structure describes a signal stack.  It contains the following members:
3058
3059 @table @code
3060 @item void *ss_sp
3061 This points to the base of the signal stack.
3062
3063 @item size_t ss_size
3064 This is the size (in bytes) of the signal stack which @samp{ss_sp} points to.
3065 You should set this to however much space you allocated for the stack.
3066
3067 There are two macros defined in @file{signal.h} that you should use in
3068 calculating this size:
3069
3070 @vtable @code
3071 @item SIGSTKSZ
3072 This is the canonical size for a signal stack.  It is judged to be
3073 sufficient for normal uses.
3074
3075 @item MINSIGSTKSZ
3076 This is the amount of signal stack space the operating system needs just
3077 to implement signal delivery.  The size of a signal stack @strong{must}
3078 be greater than this.
3079
3080 For most cases, just using @code{SIGSTKSZ} for @code{ss_size} is
3081 sufficient.  But if you know how much stack space your program's signal
3082 handlers will need, you may want to use a different size.  In this case,
3083 you should allocate @code{MINSIGSTKSZ} additional bytes for the signal
3084 stack and increase @code{ss_size} accordingly.
3085 @end vtable
3086
3087 @item int ss_flags
3088 This field contains the bitwise @sc{or} of these flags:
3089
3090 @vtable @code
3091 @item SA_DISABLE
3092 This tells the system that it should not use the signal stack.
3093
3094 @item SA_ONSTACK
3095 This is set by the system, and indicates that the signal stack is
3096 currently in use.  If this bit is not set, then signals will be
3097 delivered on the normal user stack.
3098 @end vtable
3099 @end table
3100 @end deftp
3101
3102 @comment signal.h
3103 @comment BSD
3104 @deftypefun int sigaltstack (const struct sigaltstack *@var{stack}, struct sigaltstack *@var{oldstack})
3105 The @code{sigaltstack} function specifies an alternate stack for use
3106 during signal handling.  When a signal is received by the process and
3107 its action indicates that the signal stack is used, the system arranges
3108 a switch to the currently installed signal stack while the handler for
3109 that signal is executed.
3110
3111 If @var{oldstack} is not a null pointer, information about the currently
3112 installed signal stack is returned in the location it points to.  If
3113 @var{stack} is not a null pointer, then this is installed as the new
3114 stack for use by signal handlers.
3115
3116 The return value is @code{0} on success and @code{-1} on failure.  If
3117 @code{sigaltstack} fails, it sets @code{errno} to one of these values:
3118
3119 @table @code
3120 @item
3121 @item EINVAL
3122 You tried to disable a stack that was in fact currently in use.
3123
3124 @item ENOMEM
3125 The size of the alternate stack was too small.
3126 It must be greater than @code{MINSIGSTKSZ}.
3127 @end table
3128 @end deftypefun
3129
3130 Here is the older @code{sigstack} interface.  You should use
3131 @code{sigaltstack} instead on systems that have it.
3132
3133 @comment signal.h
3134 @comment BSD
3135 @deftp {Data Type} {struct sigstack}
3136 This structure describes a signal stack.  It contains the following members:
3137
3138 @table @code
3139 @item void *ss_sp
3140 This is the stack pointer.  If the stack grows downwards on your
3141 machine, this should point to the top of the area you allocated.  If the
3142 stack grows upwards, it should point to the bottom.
3143
3144 @item int ss_onstack
3145 This field is true if the process is currently using this stack.
3146 @end table
3147 @end deftp
3148
3149 @comment signal.h
3150 @comment BSD
3151 @deftypefun int sigstack (const struct sigstack *@var{stack}, struct sigstack *@var{oldstack})
3152 The @code{sigstack} function specifies an alternate stack for use during
3153 signal handling.  When a signal is received by the process and its
3154 action indicates that the signal stack is used, the system arranges a
3155 switch to the currently installed signal stack while the handler for
3156 that signal is executed.
3157
3158 If @var{oldstack} is not a null pointer, information about the currently
3159 installed signal stack is returned in the location it points to.  If
3160 @var{stack} is not a null pointer, then this is installed as the new
3161 stack for use by signal handlers.
3162
3163 The return value is @code{0} on success and @code{-1} on failure.
3164 @end deftypefun
3165
3166 @node BSD Signal Handling
3167 @section BSD Signal Handling
3168
3169 This section describes alternative signal handling functions derived
3170 from BSD Unix.  These facilities were an advance, in their time; today,
3171 they are mostly obsolete, and supported mainly for compatibility with
3172 BSD Unix.
3173
3174 There are many similarities between the BSD and POSIX signal handling
3175 facilities, because the POSIX facilities were inspired by the BSD
3176 facilities.  Besides having different names for all the functions to
3177 avoid conflicts, the main differences between the two are:
3178
3179 @itemize @bullet
3180 @item
3181 BSD Unix represents signal masks as an @code{int} bit mask, rather than
3182 as a @code{sigset_t} object.
3183
3184 @item
3185 The BSD facilities use a different default for whether an interrupted
3186 primitive should fail or resume.  The POSIX facilities make system
3187 calls fail unless you specify that they should resume.  With the BSD
3188 facility, the default is to make system calls resume unless you say they
3189 should fail.  @xref{Interrupted Primitives}.
3190 @end itemize
3191
3192 The BSD facilities are declared in @file{signal.h}.
3193 @pindex signal.h
3194
3195 @menu
3196 * BSD Handler::                 BSD Function to Establish a Handler.
3197 * Blocking in BSD::             BSD Functions for Blocking Signals.
3198 @end menu
3199
3200 @node BSD Handler
3201 @subsection BSD Function to Establish a Handler
3202
3203 @comment signal.h
3204 @comment BSD
3205 @deftp {Data Type} {struct sigvec}
3206 This data type is the BSD equivalent of @code{struct sigaction}
3207 (@pxref{Advanced Signal Handling}); it is used to specify signal actions
3208 to the @code{sigvec} function.  It contains the following members:
3209
3210 @table @code
3211 @item sighandler_t sv_handler
3212 This is the handler function.
3213
3214 @item int sv_mask
3215 This is the mask of additional signals to be blocked while the handler
3216 function is being called.
3217
3218 @item int sv_flags
3219 This is a bit mask used to specify various flags which affect the
3220 behavior of the signal.  You can also refer to this field as
3221 @code{sv_onstack}.
3222 @end table
3223 @end deftp
3224
3225 These symbolic constants can be used to provide values for the
3226 @code{sv_flags} field of a @code{sigvec} structure.  This field is a bit
3227 mask value, so you bitwise-OR the flags of interest to you together.
3228
3229 @comment signal.h
3230 @comment BSD
3231 @deftypevr Macro int SV_ONSTACK
3232 If this bit is set in the @code{sv_flags} field of a @code{sigvec}
3233 structure, it means to use the signal stack when delivering the signal.
3234 @end deftypevr
3235
3236 @comment signal.h
3237 @comment BSD
3238 @deftypevr Macro int SV_INTERRUPT
3239 If this bit is set in the @code{sv_flags} field of a @code{sigvec}
3240 structure, it means that system calls interrupted by this kind of signal
3241 should not be restarted if the handler returns; instead, the system
3242 calls should return with a @code{EINTR} error status.  @xref{Interrupted
3243 Primitives}.
3244 @end deftypevr
3245
3246 @comment signal.h
3247 @comment Sun
3248 @deftypevr Macro int SV_RESETHAND
3249 If this bit is set in the @code{sv_flags} field of a @code{sigvec}
3250 structure, it means to reset the action for the signal back to
3251 @code{SIG_DFL} when the signal is received.
3252 @end deftypevr
3253
3254 @comment signal.h
3255 @comment BSD
3256 @deftypefun int sigvec (int @var{signum}, const struct sigvec *@var{action},struct sigvec *@var{old-action})
3257 This function is the equivalent of @code{sigaction} (@pxref{Advanced Signal
3258 Handling}); it installs the action @var{action} for the signal @var{signum},
3259 returning information about the previous action in effect for that signal
3260 in @var{old-action}.
3261 @end deftypefun
3262
3263 @comment signal.h
3264 @comment BSD
3265 @deftypefun int siginterrupt (int @var{signum}, int @var{failflag})
3266 This function specifies which approach to use when certain primitives
3267 are interrupted by handling signal @var{signum}.  If @var{failflag} is
3268 false, signal @var{signum} restarts primitives.  If @var{failflag} is
3269 true, handling @var{signum} causes these primitives to fail with error
3270 code @code{EINTR}.  @xref{Interrupted Primitives}.
3271 @end deftypefun
3272
3273 @node Blocking in BSD
3274 @subsection BSD Functions for Blocking Signals
3275
3276 @comment signal.h
3277 @comment BSD
3278 @deftypefn Macro int sigmask (int @var{signum})
3279 This macro returns a signal mask that has the bit for signal @var{signum}
3280 set.  You can bitwise-OR the results of several calls to @code{sigmask}
3281 together to specify more than one signal.  For example,
3282
3283 @smallexample
3284 (sigmask (SIGTSTP) | sigmask (SIGSTOP)
3285  | sigmask (SIGTTIN) | sigmask (SIGTTOU))
3286 @end smallexample
3287
3288 @noindent
3289 specifies a mask that includes all the job-control stop signals.
3290 @end deftypefn
3291
3292 @comment signal.h
3293 @comment BSD
3294 @deftypefun int sigblock (int @var{mask})
3295 This function is equivalent to @code{sigprocmask} (@pxref{Process Signal
3296 Mask}) with a @var{how} argument of @code{SIG_BLOCK}: it adds the
3297 signals specified by @var{mask} to the calling process's set of blocked
3298 signals.  The return value is the previous set of blocked signals.
3299 @end deftypefun
3300
3301 @comment signal.h
3302 @comment BSD
3303 @deftypefun int sigsetmask (int @var{mask})
3304 This function equivalent to @code{sigprocmask} (@pxref{Process
3305 Signal Mask}) with a @var{how} argument of @code{SIG_SETMASK}: it sets
3306 the calling process's signal mask to @var{mask}.  The return value is
3307 the previous set of blocked signals.
3308 @end deftypefun
3309
3310 @comment signal.h
3311 @comment BSD
3312 @deftypefun int sigpause (int @var{mask})
3313 This function is the equivalent of @code{sigsuspend} (@pxref{Waiting
3314 for a Signal}):  it sets the calling process's signal mask to @var{mask},
3315 and waits for a signal to arrive.  On return the previous set of blocked
3316 signals is restored.
3317 @end deftypefun