@Go to the ‰ŠP�”›first@�”˜, ‰ŠP�”›previous@�”˜, ‰ŠP�”›next@�”˜, ‰ŠP�”›last@�”˜ section, ‰ŠP�”›table of contents@�”˜.
Œ

ˆ‰SEC335Št�”›Signal Handling

‰IDX1600Š@�”˜A Bsignal@ is a software interrupt delivered to a process. The operating system uses signals to report exceptional situations to an executing program. Some signals report errors such as references to invalid memory addresses; others report asynchronous events, such as disconnection of a phone line.
The GNU C library defines a variety of signal types, each for a particular kind of event. Some kinds of events make it inadvisable or impossible for the program to proceed as usual, and the corresponding signals normally abort the program. Other kinds of signals that report harmless events are ignored by default.
If you anticipate an event that causes signals, you can define a handler function and tell the operating system to run it when that particular type of signal arrives.
Finally, one process can send a signal to another process; this allows a parent process to abort a child, or two related processes to communicate and synchronize.
ˆ‰SEC336Št�”›Basic Concepts of Signals

@�”˜This section explains basic concepts of how signals are generated, what happens after a signal is delivered, and how programs can handle signals.
ˆ‰SEC337ŠT�”›Some Kinds of Signals

@�”˜A signal reports the occurrence of an exceptional event. These are some of the events that can cause (or Bgenerate@, or Braise@) a signal: þÂ
• A program error such as dividing by zero or issuing an address outside the valid range.
• A user request to interrupt or terminate the program. Most environments are set up to let a user suspend the program by typing HC-z@, or terminate it with HC-c@. Whatever key sequence is used, the operating system sends the proper signal to interrupt the process.
• The termination of a child process.
• Expiration of a timer or alarm.
• A call to Hkill@ or Hraise@ by the same process.
• A call to Hkill@ from another process. Signals are a limited but useful form of interprocess communication.
• An attempt to perform an I/O operation that cannot be done. Examples are reading from a pipe that has no writer (see section ‰ŠP�”›Pipes and FIFOs@�”˜), and reading or writing to a terminal in certain situations (see section ‰ŠP�”›Job Control@�”˜).Àð
Each of these kinds of events (excepting explicit calls to Hkill@ and Hraise@) generates its own particular kind of signal. The various kinds of signals are listed and described in detail in section ‰ŠP�”›Standard Signals@�”˜.
ˆ‰SEC338ŠT�”›Concepts of Signal Generation

‰IDX1601Š
@�”˜In general, the events that generate signals fall into three major categories: errors, external events, and explicit requests.
An error means that a program has done something invalid and cannot continue execution. But not all kinds of errors generate signals--in fact, most do not. For example, opening a nonexistent file is an error, but it does not raise a signal; instead, Hopen@ returns H-1@. In general, errors that are necessarily associated with certain library functions are reported by returning a value that indicates an error. The errors which raise signals are those which can happen anywhere in the program, not just in library calls. These include division by zero and invalid memory addresses.
An external event generally has to do with I/O or other processes. These include the arrival of input, the expiration of a timer, and the termination of a child process.
An explicit request means the use of a library function such as Hkill@ whose purpose is specifically to generate a signal.
Signals may be generated Bsynchronously@ or Basynchronously@. A synchronous signal pertains to a specific action in the program, and is delivered (unless blocked) during that action. Most errors generate signals synchronously, and so do explicit requests by a process to generate a signal for that same process. On some machines, certain kinds of hardware errors (usually floating-point exceptions) are not reported completely synchronously, but may arrive a few instructions later.
Asynchronous signals are generated by events outside the control of the process that receives them. These signals arrive at unpredictable times during execution. External events generate signals asynchronously, and so do explicit requests that apply to some other process.
A given type of signal is either typically synchronous or typically asynchronous. For example, signals for errors are typically synchronous because errors generate signals synchronously. But any type of signal can be generated synchronously or asynchronously with an explicit request.
ˆ‰SEC339ŠT�”›How Signals Are Delivered

‰IDX1602Š‰IDX1603Š‰IDX1604Š
@�”˜When a signal is generated, it becomes Bpending@. Normally it remains pending for just a short period of time and then is Bdelivered@ to the process that was signaled. However, if that kind of signal is currently Bblocked@, it may remain pending indefinitely--until signals of that kind are Bunblocked@. Once unblocked, it will be delivered immediately. See section ‰ŠP�”›Blocking Signals@�”˜.
‰IDX1605Š‰IDX1606Š‰IDX1607Š‰IDX1608Š@�”˜When the signal is delivered, whether right away or after a long delay, the Bspecified action@ for that signal is taken. For certain signals, such as HSIGKILL@ and HSIGSTOP@, the action is fixed, but for most signals, the program has a choice: ignore the signal, specify a Bhandler function@, or accept the Bdefault action@ for that kind of signal. The program specifies its choice using functions such as Hsignal@ or Hsigaction@ (see section ‰ŠP�”›Specifying Signal Actions@�”˜). We sometimes say that a handler Bcatches@ the signal. While the handler is running, that particular signal is normally blocked.
If the specified action for a kind of signal is to ignore it, then any such signal which is generated is discarded immediately. This happens even if the signal is also blocked at the time. A signal discarded in this way will never be delivered, not even if the program subsequently specifies a different action for that kind of signal and then unblocks it.
If a signal arrives which the program has neither handled nor ignored, its Bdefault action@ takes place. Each kind of signal has its own default action, documented below (see section ‰ŠP�”›Standard Signals@�”˜). For most kinds of signals, the default action is to terminate the process. For certain kinds of signals that represent "harmless" events, the default action is to do nothing.
When a signal terminates a process, its parent process can determine the cause of termination by examining the termination status code reported by the Hwait@ or Hwaitpid@ functions. (This is discussed in more detail in section ‰ŠP�”›Process Completion@�”˜.) The information it can get includes the fact that termination was due to a signal, and the kind of signal involved. If a program you run from a shell is terminated by a signal, the shell typically prints some kind of error message.
The signals that normally represent program errors have a special property: when one of these signals terminates the process, it also writes a Bcore dump file@ which records the state of the process at the time of termination. You can examine the core dump with a debugger to investigate what caused the error.
If you raise a "program error" signal by explicit request, and this terminates the process, it makes a core dump file just as if the signal had been due directly to an error.
ˆ‰SEC340Št�”›Standard Signals

‰IDX1609Š‰IDX1610Š
‰IDX1611Š‰IDX1612Š@�”˜This section lists the names for various standard kinds of signals and describes what kind of event they mean. Each signal name is a macro which stands for a positive integer--the Bsignal number@ for that kind of signal. Your programs should never make assumptions about the numeric code for a particular kind of signal, but rather refer to them always by the names defined here. This is because the number for a given kind of signal can vary from system to system, but the meanings of the names are standardized and fairly uniform.
The signal names are defined in the header file H`signal.h'@.

AMacro:@ int DNSIG
Â‰IDX1613Š@�”˜The value of this symbolic constant is the total number of signals defined. Since the signal numbers are allocated consecutively, HNSIG@ is also one greater than the largest defined signal number.À

ˆ‰SEC341ŠT�”›Program Error Signals

‰IDX1614Š
@�”˜The following signals are generated when a serious program error is detected by the operating system or the computer itself. In general, all of these signals are indications that your program is seriously broken in some way, and there's usually no way to continue the computation which encountered the error.
Some programs handle program error signals in order to tidy up before terminating; for example, programs that turn off echoing of terminal input should handle program error signals in order to turn echoing back on. The handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See section ‰ŠP�”›Handlers That Terminate the Process@�”˜.)
Termination is the sensible ultimate outcome from a program error in most programs. However, programming systems such as Lisp that can load compiled user programs might need to keep executing even if a user program incurs an error. These programs have handlers which use Hlongjmp@ to return control to the command level.
The default action for all of these signals is to cause the process to terminate. If you block or ignore these signals or establish handlers for them that return normally, your program will probably break horribly when such signals happen, unless they are generated by Hraise@ or Hkill@ instead of a real error.
‰IDX1615Š@�”˜When one of these program error signals terminates a process, it also writes a Bcore dump file@ which records the state of the process at the time of termination. The core dump file is named H`core'@ and is written in whichever directory is current in the process at the time. (On the GNU system, you can specify the file name for core dumps with the environment variable HCOREFILE@.) The purpose of core dump files is so that you can examine them with a debugger to investigate what caused the error.

AMacro:@ int DSIGFPE
Â‰IDX1616Š@�”˜The HSIGFPE@ signal reports a fatal arithmetic error. Although the name is derived from "floating-point exception", this signal actually covers all arithmetic errors, including division by zero and overflow. If a program stores integer data in a location which is then used in a floating-point operation, this often causes an "invalid operation" exception, because the processor cannot recognize the data as a floating-point number. ‰IDX1617Š‰IDX1618Š
@�”˜Actual floating-point exceptions are a complicated subject because there are many types of exceptions with subtly different meanings, and the HSIGFPE@ signal doesn't distinguish between them. The BIEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985 and ANSI/IEEE Std 854-1987)@ defines various floating-point exceptions and requires conforming computer systems to report their occurrences. However, this standard does not specify how the exceptions are reported, or what kinds of handling and control the operating system can offer to the programmer.À

BSD systems provide the HSIGFPE@ handler with an extra argument that distinguishes various causes of the exception. In order to access this argument, you must define the handler to accept two arguments, which means you must cast it to a one-argument function type in order to establish the handler. The GNU library does provide this extra argument, but the value is meaningful only on operating systems that provide the information (BSD systems and GNU systems).
HFPE_INTOVF_TRAP
Â‰IDX1619Š@�”˜Integer overflow (impossible in a C program unless you enable overflow trapping in a hardware-specific fashion).
ÀHFPE_INTDIV_TRAP
Â‰IDX1620Š@�”˜Integer division by zero.
ÀHFPE_SUBRNG_TRAP
Â‰IDX1621Š@�”˜Subscript-range (something that C programs never check for).
ÀHFPE_FLTOVF_TRAP
Â‰IDX1622Š@�”˜Floating overflow trap.
ÀHFPE_FLTDIV_TRAP
Â‰IDX1623Š@�”˜Floating/decimal division by zero.
ÀHFPE_FLTUND_TRAP
Â‰IDX1624Š@�”˜Floating underflow trap. (Trapping on floating underflow is not normally enabled.)
ÀHFPE_DECOVF_TRAP
Â‰IDX1625Š@�”˜Decimal overflow trap. (Only a few machines have decimal arithmetic and C never uses it.)À

AMacro:@ int DSIGILL
Â‰IDX1626Š@�”˜The name of this signal is derived from "illegal instruction"; it usually means your program is trying to execute garbage or a privileged instruction. Since the C compiler generates only valid instructions, HSIGILL@ typically indicates that the executable file is corrupted, or that you are trying to execute data. Some common ways of getting into the latter situation are by passing an invalid object where a pointer to a function was expected, or by writing past the end of an automatic array (or similar problems with pointers to automatic variables) and corrupting other data on the stack such as the return address of a stack frame.
HSIGILL@ can also be generated when the stack overflows, or when the system has trouble running the handler for a signal.À
‰IDX1627Š

A�”˜Macro:@ int DSIGSEGV
Â‰IDX1628Š‰IDX1629Š@�”˜This signal is generated when a program tries to read or write outside the memory that is allocated for it, or to write memory that can only be read. (Actually, the signals only occur when the program goes far enough outside to be detected by the system's memory protection mechanism.) The name is an abbreviation for "segmentation violation".
Common ways of getting a HSIGSEGV@ condition include dereferencing a null or uninitialized pointer, or when you use a pointer to step through an array, but fail to check for the end of the array. It varies among systems whether dereferencing a null pointer generates HSIGSEGV@ or HSIGBUS@.À

AMacro:@ int DSIGBUS
Â‰IDX1630Š@�”˜This signal is generated when an invalid pointer is dereferenced. Like HSIGSEGV@, this signal is typically the result of dereferencing an uninitialized pointer. The difference between the two is that HSIGSEGV@ indicates an invalid access to valid memory, while HSIGBUS@ indicates an access to an invalid address. In particular, HSIGBUS@ signals often result from dereferencing a misaligned pointer, such as referring to a four-word integer at an address not divisible by four. (Each kind of computer has its own requirements for address alignment.)
The name of this signal is an abbreviation for "bus error".À
‰IDX1631Š

A�”˜Macro:@ int DSIGABRT
Â‰IDX1632Š‰IDX1633Š@�”˜This signal indicates an error detected by the program itself and reported by calling Habort@. See section ‰ŠP�”›Aborting a Program@�”˜.À

AMacro:@ int DSIGIOT
Â‰IDX1634Š@�”˜Generated by the PDP-11 "iot" instruction. On most machines, this is just another name for HSIGABRT@.À

AMacro:@ int DSIGTRAP
Â‰IDX1635Š@�”˜Generated by the machine's breakpoint instruction, and possibly other trap instructions. This signal is used by debuggers. Your program will probably only see HSIGTRAP@ if it is somehow executing bad instructions.À

AMacro:@ int DSIGEMT
Â‰IDX1636Š@�”˜Emulator trap; this results from certain unimplemented instructions which might be emulated in software, or the operating system's failure to properly emulate them.À

AMacro:@ int DSIGSYS
Â‰IDX1637Š@�”˜Bad system call; that is to say, the instruction to trap to the operating system was executed, but the code number for the system call to perform was invalid.À

ˆ‰SEC342ŠT�”›Termination Signals

‰IDX1638Š
@�”˜These signals are all used to tell a process to terminate, in one way or another. They have different names because they're used for slightly different purposes, and programs might want to handle them differently.
The reason for handling these signals is usually so your program can tidy up as appropriate before actually terminating. For example, you might want to save state information, delete temporary files, or restore the previous terminal modes. Such a handler should end by specifying the default action for the signal that happened and then reraising it; this will cause the program to terminate with that signal, as if it had not had a handler. (See section ‰ŠP�”›Handlers That Terminate the Process@�”˜.)
The (obvious) default action for all of these signals is to cause the process to terminate.

AMacro:@ int DSIGTERM
Â‰IDX1639Š‰IDX1640Š@�”˜The HSIGTERM@ signal is a generic signal used to cause program termination. Unlike HSIGKILL@, this signal can be blocked, handled, and ignored. It is the normal way to politely ask a program to terminate.
The shell command Hkill@ generates HSIGTERM@ by default. ‰IDX1641ŠÀ

A�”˜Macro:@ int DSIGINT
Â‰IDX1642Š‰IDX1643Š@�”˜The HSIGINT@ ("program interrupt") signal is sent when the user types the INTR character (normally HC-c@). See section ‰ŠP�”›Special Characters@�”˜, for information about terminal driver support for HC-c@.À

AMacro:@ int DSIGQUIT
Â‰IDX1644Š‰IDX1645Š‰IDX1646Š@�”˜The HSIGQUIT@ signal is similar to HSIGINT@, except that it's controlled by a different key--the QUIT character, usually HC-\@---and produces a core dump when it terminates the process, just like a program error signal. You can think of this as a program error condition "detected" by the user.
See section ‰ŠP�”›Program Error Signals@�”˜, for information about core dumps. See section ‰ŠP�”›Special Characters@�”˜, for information about terminal driver support.
Certain kinds of cleanups are best omitted in handling HSIGQUIT@. For example, if the program creates temporary files, it should handle the other termination requests by deleting the temporary files. But it is better for HSIGQUIT@ not to delete them, so that the user can examine them in conjunction with the core dump.À

AMacro:@ int DSIGKILL
Â‰IDX1647Š@�”˜The HSIGKILL@ signal is used to cause immediate program termination. It cannot be handled or ignored, and is therefore always fatal. It is also not possible to block this signal.
This signal is usually generated only by explicit request. Since it cannot be handled, you should generate it only as a last resort, after first trying a less drastic method such as HC-c@ or HSIGTERM@. If a process does not respond to any other termination signals, sending it a HSIGKILL@ signal will almost always cause it to go away.
In fact, if HSIGKILL@ fails to terminate a process, that by itself constitutes an operating system bug which you should report.
The system will generate HSIGKILL@ for a process itself under some unusual conditions where the program cannot possible continue to run (even to run a signal handler).À
‰IDX1648Š

A�”˜Macro:@ int DSIGHUP
Â‰IDX1649Š‰IDX1650Š@�”˜The HSIGHUP@ ("hang-up") signal is used to report that the user's terminal is disconnected, perhaps because a network or telephone connection was broken. For more information about this, see section ‰ŠP�”›Control Modes@�”˜.
This signal is also used to report the termination of the controlling process on a terminal to jobs associated with that session; this termination effectively disconnects all processes in the session from the controlling terminal. For more information, see section ‰ŠP�”›Termination Internals@�”˜.À

ˆ‰SEC343ŠT�”›Alarm Signals

@�”˜These signals are used to indicate the expiration of timers. See section ‰ŠP�”›Setting an Alarm@�”˜, for information about functions that cause these signals to be sent.
The default behavior for these signals is to cause program termination. This default is rarely useful, but no other default would be useful; most of the ways of using these signals would require handler functions in any case.

AMacro:@ int DSIGALRM
Â‰IDX1651Š@�”˜This signal typically indicates expiration of a timer that measures real or clock time. It is used by the Halarm@ function, for example.À
‰IDX1652Š

A�”˜Macro:@ int DSIGVTALRM
Â‰IDX1653Š@�”˜This signal typically indicates expiration of a timer that measures CPU time used by the current process. The name is an abbreviation for "virtual time alarm".À
‰IDX1654Š

A�”˜Macro:@ int DSIGPROF
Â‰IDX1655Š@�”˜This signal is typically indicates expiration of a timer that measures both CPU time used by the current process, and CPU time expended on behalf of the process by the system. Such a timer is used to implement code profiling facilities, hence the name of this signal.À
‰IDX1656Š
ˆ‰SEC344ŠT�”›Asynchronous I/O Signals

@�”˜The signals listed in this section are used in conjunction with asynchronous I/O facilities. You have to take explicit action by calling Hfcntl@ to enable a particular file descriptor to generate these signals (see section ‰ŠP�”›Interrupt-Driven Input@�”˜). The default action for these signals is to ignore them.

AMacro:@ int DSIGIO
Â‰IDX1657Š‰IDX1658Š‰IDX1659Š@�”˜This signal is sent when a file descriptor is ready to perform input or output.
On most operating systems, terminals and sockets are the only kinds of files that can generate HSIGIO@; other kinds, including ordinary files, never generate HSIGIO@ even if you ask them to.
In the GNU system HSIGIO@ will always be generated properly if you successfully set asynchronous mode with Hfcntl@.À

AMacro:@ int DSIGURG
Â‰IDX1660Š‰IDX1661Š@�”˜This signal is sent when "urgent" or out-of-band data arrives on a socket. See section ‰ŠP�”›Out-of-Band Data@�”˜.À

AMacro:@ int DSIGPOLL
Â‰IDX1662Š@�”˜This is a System V signal name, more or less similar to HSIGIO@. It is defined only for compatibility.À

ˆ‰SEC345ŠT�”›Job Control Signals

‰IDX1663Š
@�”˜These signals are used to support job control. If your system doesn't support job control, then these macros are defined but the signals themselves can't be raised or handled.
You should generally leave these signals alone unless you really understand how job control works. See section ‰ŠP�”›Job Control@�”˜.

AMacro:@ int DSIGCHLD
Â‰IDX1664Š‰IDX1665Š@�”˜This signal is sent to a parent process whenever one of its child processes terminates or stops.
The default action for this signal is to ignore it. If you establish a handler for this signal while there are child processes that have terminated but not reported their status via Hwait@ or Hwaitpid@ (see section ‰ŠP�”›Process Completion@�”˜), whether your new handler applies to those processes or not depends on the particular operating system.À

AMacro:@ int DSIGCLD
Â‰IDX1666Š@�”˜This is an obsolete name for HSIGCHLD@.À

AMacro:@ int DSIGCONT
Â‰IDX1667Š‰IDX1668Š@�”˜You can send a HSIGCONT@ signal to a process to make it continue. This signal is special--it always makes the process continue if it is stopped, before the signal is delivered. The default behavior is to do nothing else. You cannot block this signal. You can set a handler, but HSIGCONT@ always makes the process continue regardless.
Most programs have no reason to handle HSIGCONT@; they simply resume execution without realizing they were ever stopped. You can use a handler for HSIGCONT@ to make a program do something special when it is stopped and continued--for example, to reprint a prompt when it is suspended while waiting for input.À

AMacro:@ int DSIGSTOP
Â‰IDX1669Š@�”˜The HSIGSTOP@ signal stops the process. It cannot be handled, ignored, or blocked.À
‰IDX1670Š

A�”˜Macro:@ int DSIGTSTP
Â‰IDX1671Š@�”˜The HSIGTSTP@ signal is an interactive stop signal. Unlike HSIGSTOP@, this signal can be handled and ignored.
Your program should handle this signal if you have a special need to leave files or system tables in a secure state when a process is stopped. For example, programs that turn off echoing should handle HSIGTSTP@ so they can turn echoing back on before stopping.
This signal is generated when the user types the SUSP character (normally HC-z@). For more information about terminal driver support, see section ‰ŠP�”›Special Characters@�”˜.À
‰IDX1672Š

A�”˜Macro:@ int DSIGTTIN
Â‰IDX1673Š@�”˜A process cannot read from the the user's terminal while it is running as a background job. When any process in a background job tries to read from the terminal, all of the processes in the job are sent a HSIGTTIN@ signal. The default action for this signal is to stop the process. For more information about how this interacts with the terminal driver, see section ‰ŠP�”›Access to the Controlling Terminal@�”˜.À
‰IDX1674Š

A�”˜Macro:@ int DSIGTTOU
Â‰IDX1675Š@�”˜This is similar to HSIGTTIN@, but is generated when a process in a background job attempts to write to the terminal or set its modes. Again, the default action is to stop the process. HSIGTTOU@ is only generated for an attempt to write to the terminal if the HTOSTOP@ output mode is set; see section ‰ŠP�”›Output Modes@�”˜.À
‰IDX1676Š
@�”˜While a process is stopped, no more signals can be delivered to it until it is continued, except HSIGKILL@ signals and (obviously) HSIGCONT@ signals. The signals are marked as pending, but not delivered until the process is continued. The HSIGKILL@ signal always causes termination of the process and can't be blocked, handled or ignored. You can ignore HSIGCONT@, but it always causes the process to be continued anyway if it is stopped. Sending a HSIGCONT@ signal to a process causes any pending stop signals for that process to be discarded. Likewise, any pending HSIGCONT@ signals for a process are discarded when it receives a stop signal.
When a process in an orphaned process group (see section ‰ŠP�”›Orphaned Process Groups@�”˜) receives a HSIGTSTP@, HSIGTTIN@, or HSIGTTOU@ signal and does not handle it, the process does not stop. Stopping the process would probably not be very useful, since there is no shell program that will notice it stop and allow the user to continue it. What happens instead depends on the operating system you are using. Some systems may do nothing; others may deliver another signal instead, such as HSIGKILL@ or HSIGHUP@. In the GNU system, the process dies with HSIGKILL@; this avoids the problem of many stopped, orphaned processes lying around the system.
ˆ‰SEC346ŠT�”›Operation Error Signals

@�”˜These signals are used to report various errors generated by an operation done by the program. They do not necessarily indicate a programming error in the program, but an error that prevents an operating system call from completing. The default action for all of them is to cause the process to terminate.

AMacro:@ int DSIGPIPE
Â‰IDX1677Š‰IDX1678Š‰IDX1679Š@�”˜Broken pipe. If you use pipes or FIFOs, you have to design your application so that one process opens the pipe for reading before another starts writing. If the reading process never starts, or terminates unexpectedly, writing to the pipe or FIFO raises a HSIGPIPE@ signal. If HSIGPIPE@ is blocked, handled or ignored, the offending call fails with HEPIPE@ instead.
Pipes and FIFO special files are discussed in more detail in section ‰ŠP�”›Pipes and FIFOs@�”˜.
Another cause of HSIGPIPE@ is when you try to output to a socket that isn't connected. See section ‰ŠP�”›Sending Data@�”˜.À

AMacro:@ int DSIGLOST
Â‰IDX1680Š‰IDX1681Š@�”˜Resource lost. This signal is generated when you have an advisory lock on an NFS file, and the NFS server reboots and forgets about your lock.
In the GNU system, HSIGLOST@ is generated when any server program dies unexpectedly. It is usually fine to ignore the signal; whatever call was made to the server that died just returns an error.À

AMacro:@ int DSIGXCPU
Â‰IDX1682Š@�”˜CPU time limit exceeded. This signal is generated when the process exceeds its soft resource limit on CPU time. See section ‰ŠP�”›Limiting Resource Usage@�”˜.À

AMacro:@ int DSIGXFSZ
Â‰IDX1683Š@�”˜File size limit exceeded. This signal is generated when the process attempts to extend a file so it exceeds the process's soft resource limit on file size. See section ‰ŠP�”›Limiting Resource Usage@�”˜.À

ˆ‰SEC347ŠT�”›Miscellaneous Signals

@�”˜These signals are used for various other purposes. In general, they will not affect your program unless it explicitly uses them for something.

AMacro:@ int DSIGUSR1
Â‰IDX1684ŠÀ

A�”˜Macro:@ int DSIGUSR2
Â‰IDX1685Š‰IDX1686Š@�”˜The HSIGUSR1@ and HSIGUSR2@ signals are set aside for you to use any way you want. They're useful for simple interprocess communication, if you write a signal handler for them in the program that receives the signal.
There is an example showing the use of HSIGUSR1@ and HSIGUSR2@ in section ‰ŠP�”›Signaling Another Process@�”˜.
The default action is to terminate the process.À

AMacro:@ int DSIGWINCH
Â‰IDX1687Š@�”˜Window size change. This is generated on some systems (including GNU) when the terminal driver's record of the number of rows and columns on the screen is changed. The default action is to ignore it.
If a program does full-screen display, it should handle HSIGWINCH@. When the signal arrives, it should fetch the new screen size and reformat its display accordingly.À

AMacro:@ int DSIGINFO
Â‰IDX1688Š@�”˜Information request. In 4.4 BSD and the GNU system, this signal is sent to all the processes in the foreground process group of the controlling terminal when the user types the STATUS character in canonical mode; see section ‰ŠP�”›Characters that Cause Signals@�”˜.
If the process is the leader of the process group, the default action is to print some status information about the system and what the process is doing. Otherwise the default is to do nothing.À

ˆ‰SEC348ŠT�”›Signal Messages

‰IDX1689Š
@�”˜We mentioned above that the shell prints a message describing the signal that terminated a child process. The clean way to print a message describing a signal is to use the functions Hstrsignal@ and Hpsignal@. These functions use a signal number to specify which kind of signal to describe. The signal number may come from the termination status of a child process (see section ‰ŠP�”›Process Completion@�”˜) or it may come from a signal handler in the same process.

AFunction:@ char * Dstrsignal@ B(int Bsignum@)
Â‰IDX1690Š@�”˜This function returns a pointer to a statically-allocated string containing a message describing the signal Bsignum@. You should not modify the contents of this string; and, since it can be rewritten on subsequent calls, you should save a copy of it if you need to reference it later.
‰IDX1691Š@�”˜This function is a GNU extension, declared in the header file H`string.h'@.À

AFunction:@ void Dpsignal@ B(int Bsignum@, const char *Bmessage@)
Â‰IDX1692Š@�”˜This function prints a message describing the signal Bsignum@ to the standard error output stream Hstderr@; see section ‰ŠP�”›Standard Streams@�”˜.
If you call Hpsignal@ with a Bmessage@ that is either a null pointer or an empty string, Hpsignal@ just prints the message corresponding to Bsignum@, adding a trailing newline.
If you supply a non-null Bmessage@ argument, then Hpsignal@ prefixes its output with this string. It adds a colon and a space character to separate the Bmessage@ from the string corresponding to Bsignum@.
‰IDX1693Š@�”˜This function is a BSD feature, declared in the header file H`signal.h'@.À

‰IDX1694Š@�”˜There is also an array Hsys_siglist@ which contains the messages for the various signal codes. This array exists on BSD systems, unlike Hstrsignal@.
ˆ‰SEC349Št�”›Specifying Signal Actions

‰IDX1695Š‰IDX1696Š
@�”˜The simplest way to change the action for a signal is to use the Hsignal@ function. You can specify a built-in action (such as to ignore the signal), or you can Bestablish a handler@.
The GNU library also implements the more versatile Hsigaction@ facility. This section describes both facilities and gives suggestions on which to use when.
ˆ‰SEC350ŠT�”›Basic Signal Handling

‰IDX1697Š
@�”˜The Hsignal@ function provides a simple interface for establishing an action for a particular signal. The function and associated macros are declared in the header file H`signal.h'@. ‰IDX1698Š

A�”˜Data Type:@ Dsighandler_t
Â‰IDX1699Š@�”˜This is the type of signal handler functions. Signal handlers take one integer argument specifying the signal number, and have return type Hvoid@. So, you should define handler functions like this: void Bhandler@ (int Hsignum@) { ... }
The name Hsighandler_t@ for this data type is a GNU extension.À

AFunction:@ sighandler_t Dsignal@ B(int Bsignum@, sighandler_t Baction@)
Â‰IDX1700Š@�”˜The Hsignal@ function establishes Baction@ as the action for the signal Bsignum@.
The first argument, Bsignum@, identifies the signal whose behavior you want to control, and should be a signal number. The proper way to specify a signal number is with one of the symbolic signal names described in section ‰ŠP�”›Standard Signals@�”˜---don't use an explicit number, because the numerical code for a given kind of signal may vary from operating system to operating system.
The second argument, Baction@, specifies the action to use for the signal Bsignum@. This can be one of the following:
HSIG_DFL
Ä‰IDX1701Š‰IDX1702ŠH�”˜SIG_DFL@ specifies the default action for the particular signal. The default actions for various kinds of signals are stated in section ‰ŠP�”›Standard Signals@�”˜.
ÂHSIG_IGN
Ä‰IDX1703Š‰IDX1704ŠH�”˜SIG_IGN@ specifies that the signal should be ignored. Your program generally should not ignore signals that represent serious events or that are normally used to request termination. You cannot ignore the HSIGKILL@ or HSIGSTOP@ signals at all. You can ignore program error signals like HSIGSEGV@, but ignoring the error won't enable the program to continue executing meaningfully. Ignoring user requests such as HSIGINT@, HSIGQUIT@, and HSIGTSTP@ is unfriendly. When you do not wish signals to be delivered during a certain part of the program, the thing to do is to block them, not ignore them. See section ‰ŠP�”›Blocking Signals@�”˜.
ÂJhandler
Ä@Supply the address of a handler function in your program, to specify running this handler as the way to deliver the signal. For more information about defining signal handler functions, see section ‰ŠP�”›Defining Signal Handlers@�”˜.Â

If you set the action for a signal to HSIG_IGN@, or if you set it to HSIG_DFL@ and the default action is to ignore that signal, then any pending signals of that type are discarded (even if they are blocked). Discarding the pending signals means that they will never be delivered, not even if you subsequently specify another action and unblock this kind of signal.
The Hsignal@ function returns the action that was previously in effect for the specified Bsignum@. You can save this value and restore it later by calling Hsignal@ again.
If Hsignal@ can't honor the request, it returns HSIG_ERR@ instead. The following Herrno@ error conditions are defined for this function:
HEINVAL
Ä@You specified an invalid Bsignum@; or you tried to ignore or provide a handler for HSIGKILL@ or HSIGSTOP@.Â
À

Here is a simple example of setting up a handler to delete temporary files when certain fatal signals happen: #include <signal.h>

void
termination_handler (int signum)
{
struct temp_file *p;

for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}

int
main (void)
{
...
if (signal (SIGINT, termination_handler) == SIG_IGN)
signal (SIGINT, SIG_IGN);
if (signal (SIGHUP, termination_handler) == SIG_IGN)
signal (SIGHUP, SIG_IGN);
if (signal (SIGTERM, termination_handler) == SIG_IGN)
signal (SIGTERM, SIG_IGN);
...
}
Note how if a given signal was previously set to be ignored, this code avoids altering that setting. This is because non-job-control shells often ignore certain signals when starting children, and it is important for the children to respect this.
We do not handle HSIGQUIT@ or the program error signals in this example because these are designed to provide information for debugging (a core dump), and the temporary files may give useful information.

AFunction:@ sighandler_t Dssignal@ B(int Bsignum@, sighandler_t Baction@)
Â‰IDX1705Š@�”˜The Hssignal@ function does the same thing as Hsignal@; it is provided only for compatibility with SVID.À

AMacro:@ sighandler_t DSIG_ERR
Â‰IDX1706Š@�”˜The value of this macro is used as the return value from Hsignal@ to indicate an error.À

ˆ‰SEC351ŠT�”›Advanced Signal Handling

‰IDX1707Š
@�”˜The Hsigaction@ function has the same basic effect as Hsignal@: to specify how a signal should be handled by the process. However, Hsigaction@ offers more control, at the expense of more complexity. In particular, Hsigaction@ allows you to specify additional flags to control when the signal is generated and how the handler is invoked.
The Hsigaction@ function is declared in H`signal.h'@. ‰IDX1708Š

A�”˜Data Type:@ Dstruct sigaction
Â‰IDX1709Š@�”˜Structures of type Hstruct sigaction@ are used in the Hsigaction@ function to specify all the information about how to handle a particular signal. This structure contains at least the following members:
Hsighandler_t sa_handler
Ä@This is used in the same way as the Baction@ argument to the Hsignal@ function. The value can be HSIG_DFL@, HSIG_IGN@, or a function pointer. See section ‰ŠP�”›Basic Signal Handling@�”˜.
ÂHsigset_t sa_mask
Ä@This specifies a set of signals to be blocked while the handler runs. Blocking is explained in section ‰ŠP�”›Blocking Signals for a Handler@�”˜. Note that the signal that was delivered is automatically blocked by default before its handler is started; this is true regardless of the value in Hsa_mask@. If you want that signal not to be blocked within its handler, you must write code in the handler to unblock it.
ÂHint sa_flags
Ä@This specifies various flags which can affect the behavior of the signal. These are described in more detail in section ‰ŠP�”›Flags for Xsigaction@�”˜.Â
À

AFunction:@ int Dsigaction@ B(int Bsignum@, const struct sigaction *Baction@, struct sigaction *Bold-action@)
Â‰IDX1710Š@�”˜The Baction@ argument is used to set up a new action for the signal Bsignum@, while the Bold-action@ argument is used to return information about the action previously associated with this symbol. (In other words, Bold-action@ has the same purpose as the Hsignal@ function's return value--you can check to see what the old action in effect for the signal was, and restore it later if you want.)
Either Baction@ or Bold-action@ can be a null pointer. If Bold-action@ is a null pointer, this simply suppresses the return of information about the old action. If Baction@ is a null pointer, the action associated with the signal Bsignum@ is unchanged; this allows you to inquire about how a signal is being handled without changing that handling.
The return value from Hsigaction@ is zero if it succeeds, and H-1@ on failure. The following Herrno@ error conditions are defined for this function:
HEINVAL
Ä@The Bsignum@ argument is not valid, or you are trying to trap or ignore HSIGKILL@ or HSIGSTOP@.Â
À

ˆ‰SEC352ŠT�”›Interaction of \signalT and \sigaction

@�”˜It's possible to use both the Hsignal@ and Hsigaction@ functions within a single program, but you have to be careful because they can interact in slightly strange ways.
The Hsigaction@ function specifies more information than the Hsignal@ function, so the return value from Hsignal@ cannot express the full range of Hsigaction@ possibilities. Therefore, if you use Hsignal@ to save and later reestablish an action, it may not be able to reestablish properly a handler that was established with Hsigaction@.
To avoid having problems as a result, always use Hsigaction@ to save and restore a handler if your program uses Hsigaction@ at all. Since Hsigaction@ is more general, it can properly save and reestablish any action, regardless of whether it was established originally with Hsignal@ or Hsigaction@.
On some systems if you establish an action with Hsignal@ and then examine it with Hsigaction@, the handler address that you get may not be the same as what you specified with Hsignal@. It may not even be suitable for use as an action argument with Hsignal@. But you can rely on using it as an argument to Hsigaction@. This problem never happens on the GNU system.
So, you're better off using one or the other of the mechanisms consistently within a single program.
DPortability Note:@ The basic Hsignal@ function is a feature of ISO C, while Hsigaction@ is part of the POSIX.1 standard. If you are concerned about portability to non-POSIX systems, then you should use the Hsignal@ function instead.
ˆ‰SEC353Š\�”›sigactionT Function Example

@�”˜In section ‰ŠP�”›Basic Signal Handling@�”˜, we gave an example of establishing a simple handler for termination signals using Hsignal@. Here is an equivalent example using Hsigaction@: #include <signal.h>

void
termination_handler (int signum)
{
struct temp_file *p;

for (p = temp_file_list; p; p = p->next)
unlink (p->name);
}

int
main (void)
{
...
struct sigaction new_action, old_action;

/* Set up the structure to specify the new action. */
new_action.sa_handler = termination_handler;
sigemptyset (&new_action.sa_mask);
new_action.sa_flags = 0;

sigaction (SIGINT, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGINT, &new_action, NULL);
sigaction (SIGHUP, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGHUP, &new_action, NULL);
sigaction (SIGTERM, NULL, &old_action);
if (old_action.sa_handler != SIG_IGN)
sigaction (SIGTERM, &new_action, NULL);
...
}
The program just loads the Hnew_action@ structure with the desired parameters and passes it in the Hsigaction@ call. The usage of Hsigemptyset@ is described later; see section ‰ŠP�”›Blocking Signals@�”˜.
As in the example using Hsignal@, we avoid handling signals previously set to be ignored. Here we can avoid altering the signal handler even momentarily, by using the feature of Hsigaction@ that lets us examine the current action without specifying a new one.
Here is another example. It retrieves information about the current action for HSIGINT@ without changing that action. struct sigaction query_action;

if (sigaction (SIGINT, NULL, &query_action) < 0)
/* Hsigaction@ returns -1 in case of error. */
else if (query_action.sa_handler == SIG_DFL)
/* HSIGINT@ is handled in the default, fatal manner. */
else if (query_action.sa_handler == SIG_IGN)
/* HSIGINT@ is ignored. */
else
/* A programmer-defined signal handler is in effect. */
ˆ‰SEC354ŠT�”›Flags for \sigaction

‰IDX1711Š‰IDX1712Š‰IDX1713Š
@�”˜The Hsa_flags@ member of the Hsigaction@ structure is a catch-all for special features. Most of the time, HSA_RESTART@ is a good value to use for this field.
The value of Hsa_flags@ is interpreted as a bit mask. Thus, you should choose the flags you want to set, OR those flags together, and store the result in the Hsa_flags@ member of your Hsigaction@ structure.
Each signal number has its own set of flags. Each call to Hsigaction@ affects one particular signal number, and the flags that you specify apply only to that particular signal.
In the GNU C library, establishing a handler with Hsignal@ sets all the flags to zero except for HSA_RESTART@, whose value depends on the settings you have made with Hsiginterrupt@. See section ‰ŠP�”›Primitives Interrupted by Signals@�”˜, to see what this is about.
‰IDX1714Š@�”˜These macros are defined in the header file H`signal.h'@.

AMacro:@ int DSA_NOCLDSTOP
Â‰IDX1715Š@�”˜This flag is meaningful only for the HSIGCHLD@ signal. When the flag is set, the system delivers the signal for a terminated child process but not for one that is stopped. By default, HSIGCHLD@ is delivered for both terminated children and stopped children.
Setting this flag for a signal other than HSIGCHLD@ has no effect.À

AMacro:@ int DSA_ONSTACK
Â‰IDX1716Š@�”˜If this flag is set for a particular signal number, the system uses the signal stack when delivering that kind of signal. See section ‰ŠP�”›Using a Separate Signal Stack@�”˜. If a signal with this flag arrives and you have not set a signal stack, the system terminates the program with HSIGILL@.À

AMacro:@ int DSA_RESTART
Â‰IDX1717Š@�”˜This flag controls what happens when a signal is delivered during certain primitives (such as Hopen@, Hread@ or Hwrite@), and the signal handler returns normally. There are two alternatives: the library function can resume, or it can return failure with error code HEINTR@.
The choice is controlled by the HSA_RESTART@ flag for the particular kind of signal that was delivered. If the flag is set, returning from a handler resumes the library function. If the flag is clear, returning from a handler makes the function fail. See section ‰ŠP�”›Primitives Interrupted by Signals@�”˜.À

ˆ‰SEC355ŠT�”›Initial Signal Actions

‰IDX1718Š
@�”˜When a new process is created (see section ‰ŠP�”›Creating a Process@�”˜), it inherits handling of signals from its parent process. However, when you load a new process image using the Hexec@ function (see section ‰ŠP�”›Executing a File@�”˜), any signals that you've defined your own handlers for revert to their HSIG_DFL@ handling. (If you think about it a little, this makes sense; the handler functions from the old program are specific to that program, and aren't even present in the address space of the new program image.) Of course, the new program can establish its own handlers.
When a program is run by a shell, the shell normally sets the initial actions for the child process to HSIG_DFL@ or HSIG_IGN@, as appropriate. It's a good idea to check to make sure that the shell has not set up an initial action of HSIG_IGN@ before you establish your own signal handlers.
Here is an example of how to establish a handler for HSIGHUP@, but not if HSIGHUP@ is currently ignored: ...
struct sigaction temp;

sigaction (SIGHUP, NULL, &temp);

if (temp.sa_handler != SIG_IGN)
{
temp.sa_handler = handle_sighup;
sigemptyset (&temp.sa_mask);
sigaction (SIGHUP, &temp, NULL);
}
ˆ‰SEC356Št�”›Defining Signal Handlers

‰IDX1719Š
@�”˜This section describes how to write a signal handler function that can be established with the Hsignal@ or Hsigaction@ functions.
A signal handler is just a function that you compile together with the rest of the program. Instead of directly invoking the function, you use Hsignal@ or Hsigaction@ to tell the operating system to call it when a signal arrives. This is known as Bestablishing@ the handler. See section ‰ŠP�”›Specifying Signal Actions@�”˜.
There are two basic strategies you can use in signal handler functions: þÂ
• You can have the handler function note that the signal arrived by tweaking some global data structures, and then return normally.
• You can have the handler function terminate the program or transfer control to a point where it can recover from the situation that caused the signal.Àð
You need to take special care in writing handler functions because they can be called asynchronously. That is, a handler might be called at any point in the program, unpredictably. If two signals arrive during a very short interval, one handler can run within another. This section describes what your handler should do, and what you should avoid.
ˆ‰SEC357ŠT�”›Signal Handlers that Return

@�”˜Handlers which return normally are usually used for signals such as HSIGALRM@ and the I/O and interprocess communication signals. But a handler for HSIGINT@ might also return normally after setting a flag that tells the program to exit at a convenient time.
It is not safe to return normally from the handler for a program error signal, because the behavior of the program when the handler function returns is not defined after a program error. See section ‰ŠP�”›Program Error Signals@�”˜.
Handlers that return normally must modify some global variable in order to have any effect. Typically, the variable is one that is examined periodically by the program during normal operation. Its data type should be Hsig_atomic_t@ for reasons described in section ‰ŠP�”›Atomic Data Access and Signal Handling@�”˜.
Here is a simple example of such a program. It executes the body of the loop until it has noticed that a HSIGALRM@ signal has arrived. This technique is useful because it allows the iteration in progress when the signal arrives to complete before the loop exits. #include <signal.h>
#include <stdio.h>
#include <stdlib.h>

/* This flag controls termination of the main loop. */
volatile sig_atomic_t keep_going = 1;

/* The signal handler just clears the flag and re-enables itself. */
void
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}

void
do_stuff (void)
{
puts ("Doing stuff while waiting for alarm....");
}

int
main (void)
{
/* Establish a handler for SIGALRM signals. */
signal (SIGALRM, catch_alarm);

/* Set an alarm to go off in a little while. */
alarm (2);

/* Check the flag once in a while to see when to quit. */
while (keep_going)
do_stuff ();

return EXIT_SUCCESS;
}
ˆ‰SEC358ŠT�”›Handlers That Terminate the Process

@�”˜Handler functions that terminate the program are typically used to cause orderly cleanup or recovery from program error signals and interactive interrupts.
The cleanest way for a handler to terminate the process is to raise the same signal that ran the handler in the first place. Here is how to do this: volatile sig_atomic_t fatal_error_in_progress = 0;

void
fatal_error_signal (int sig)
{
/* Since this handler is established for more than one kind of signal,
it might still get invoked recursively by delivery of some other kind
of signal. Use a static variable to keep track of that. */
if (fatal_error_in_progress)
raise (sig);
fatal_error_in_progress = 1;

/* Now do the clean up actions:
- reset terminal modes
- kill child processes
- remove lock files */
...

/* Now reraise the signal. Since the signal is blocked,
it will receive its default handling, which is
to terminate the process. We could just call
Hexit@ or Habort@, but reraising the signal
sets the return status from the process correctly. */
raise (sig);
}
ˆ‰SEC359ŠT�”›Nonlocal Control Transfer in Handlers

‰IDX1720Š
@�”˜You can do a nonlocal transfer of control out of a signal handler using the Hsetjmp@ and Hlongjmp@ facilities (see section ‰ŠP�”›Non-Local Exits@�”˜).
When the handler does a nonlocal control transfer, the part of the program that was running will not continue. If this part of the program was in the middle of updating an important data structure, the data structure will remain inconsistent. Since the program does not terminate, the inconsistency is likely to be noticed later on.
There are two ways to avoid this problem. One is to block the signal for the parts of the program that update important data structures. Blocking the signal delays its delivery until it is unblocked, once the critical updating is finished. See section ‰ŠP�”›Blocking Signals@�”˜.
The other way to re-initialize the crucial data structures in the signal handler, or make their values consistent.
Here is a rather schematic example showing the reinitialization of one global variable. #include <signal.h>
#include <setjmp.h>

jmp_buf return_to_top_level;

volatile sig_atomic_t waiting_for_input;

void
handle_sigint (int signum)
{
/* We may have been waiting for input when the signal arrived,
but we are no longer waiting once we transfer control. */
waiting_for_input = 0;
longjmp (return_to_top_level, 1);
}

int
main (void)
{
...
signal (SIGINT, sigint_handler);
...
while (1) {
prepare_for_command ();
if (setjmp (return_to_top_level) == 0)
read_and_execute_command ();
}
}

/* Imagine this is a subroutine used by various commands. */
char *
read_data ()
{
if (input_from_terminal) {
waiting_for_input = 1;
...
waiting_for_input = 0;
} else {
...
}
}
ˆ‰SEC360ŠT�”›Signals Arriving While a Handler Runs

‰IDX1721Š
@�”˜What happens if another signal arrives while your signal handler function is running?
When the handler for a particular signal is invoked, that signal is automatically blocked until the handler returns. That means that if two signals of the same kind arrive close together, the second one will be held until the first has been handled. (The handler can explicitly unblock the signal using Hsigprocmask@, if you want to allow more signals of this type to arrive; see section ‰ŠP�”›Process Signal Mask@�”˜.)
However, your handler can still be interrupted by delivery of another kind of signal. To avoid this, you can use the Hsa_mask@ member of the action structure passed to Hsigaction@ to explicitly specify which signals should be blocked while the signal handler runs. These signals are in addition to the signal for which the handler was invoked, and any other signals that are normally blocked by the process. See section ‰ŠP�”›Blocking Signals for a Handler@�”˜.
When the handler returns, the set of blocked signals is restored to the value it had before the handler ran. So using Hsigprocmask@ inside the handler only affects what signals can arrive during the execution of the handler itself, not what signals can arrive once the handler returns.
DPortability Note:@ Always use Hsigaction@ to establish a handler for a signal that you expect to receive asynchronously, if you want your program to work properly on System V Unix. On this system, the handling of a signal whose handler was established with Hsignal@ automatically sets the signal's action back to HSIG_DFL@, and the handler must re-establish itself each time it runs. This practice, while inconvenient, does work when signals cannot arrive in succession. However, if another signal can arrive right away, it may arrive before the handler can re-establish itself. Then the second signal would receive the default handling, which could terminate the process.
ˆ‰SEC361ŠT�”›Signals Close Together Merge into One

‰IDX1722Š‰IDX1723Š‰IDX1724Š
@�”˜If multiple signals of the same type are delivered to your process before your signal handler has a chance to be invoked at all, the handler may only be invoked once, as if only a single signal had arrived. In effect, the signals merge into one. This situation can arise when the signal is blocked, or in a multiprocessing environment where the system is busy running some other processes while the signals are delivered. This means, for example, that you cannot reliably use a signal handler to count signals. The only distinction you can reliably make is whether at least one signal has arrived since a given time in the past.
Here is an example of a handler for HSIGCHLD@ that compensates for the fact that the number of signals recieved may not equal the number of child processes generate them. It assumes that the program keeps track of all the child processes with a chain of structures as follows: struct process
{
struct process *next;
/* The process ID of this child. */
int pid;
/* The descriptor of the pipe or pseudo terminal
on which output comes from this child. */
int input_descriptor;
/* Nonzero if this process has stopped or terminated. */
sig_atomic_t have_status;
/* The status of this child; 0 if running,
otherwise a status value from Hwaitpid@. */
int status;
};

struct process *process_list;
This example also uses a flag to indicate whether signals have arrived since some time in the past--whenever the program last cleared it to zero. /* Nonzero means some child's status has changed
so look at Hprocess_list@ for the details. */
int process_status_change;
Here is the handler itself: void
sigchld_handler (int signo)
{
int old_errno = errno;

while (1) {
register int pid;
int w;
struct process *p;

/* Keep asking for a status until we get a definitive result. */
do
{
errno = 0;
pid = waitpid (WAIT_ANY, &w, WNOHANG | WUNTRACED);
}
while (pid <= 0 && errno == EINTR);

if (pid <= 0) {
/* A real failure means there are no more
stopped or terminated child processes, so return. */
errno = old_errno;
return;
}

/* Find the process that signaled us, and record its status. */

for (p = process_list; p; p = p->next)
if (p->pid == pid) {
p->status = w;
/* Indicate that the Hstatus@ field
has data to look at. We do this only after storing it. */
p->have_status = 1;

/* If process has terminated, stop waiting for its output. */
if (WIFSIGNALED (w) || WIFEXITED (w))
if (p->input_descriptor)
FD_CLR (p->input_descriptor, &input_wait_mask);

/* The program should check this flag from time to time
to see if there is any news in Hprocess_list@. */
++process_status_change;
}

/* Loop around to handle all the processes
that have something to tell us. */
}
}
Here is the proper way to check the flag Hprocess_status_change@: if (process_status_change) {
struct process *p;
process_status_change = 0;
for (p = process_list; p; p = p->next)
if (p->have_status) {
... Examine Hp->status@ ...
}
}
It is vital to clear the flag before examining the list; otherwise, if a signal were delivered just before the clearing of the flag, and after the appropriate element of the process list had been checked, the status change would go unnoticed until the next signal arrived to set the flag again. You could, of course, avoid this problem by blocking the signal while scanning the list, but it is much more elegant to guarantee correctness by doing things in the right order.
The loop which checks process status avoids examining Hp->status@ until it sees that status has been validly stored. This is to make sure that the status cannot change in the middle of accessing it. Once Hp->have_status@ is set, it means that the child process is stopped or terminated, and in either case, it cannot stop or terminate again until the program has taken notice. See section ‰ŠP�”›Atomic Usage Patterns@�”˜, for more information about coping with interruptions during accessings of a variable.
Here is another way you can test whether the handler has run since the last time you checked. This technique uses a counter which is never changed outside the handler. Instead of clearing the count, the program remembers the previous value and sees whether it has changed since the previous check. The advantage of this method is that different parts of the program can check independently, each part checking whether there has been a signal since that part last checked. sig_atomic_t process_status_change;

sig_atomic_t last_process_status_change;

...
{
sig_atomic_t prev = last_process_status_change;
last_process_status_change = process_status_change;
if (last_process_status_change != prev) {
struct process *p;
for (p = process_list; p; p = p->next)
if (p->have_status) {
... Examine Hp->status@ ...
}
}
}
ˆ‰SEC362ŠT�”›Signal Handling and Nonreentrant Functions

‰IDX1725Š
@�”˜Handler functions usually don't do very much. The best practice is to write a handler that does nothing but set an external variable that the program checks regularly, and leave all serious work to the program. This is best because the handler can be called at asynchronously, at unpredictable times--perhaps in the middle of a primitive function, or even between the beginning and the end of a C operator that requires multiple instructions. The data structures being manipulated might therefore be in an inconsistent state when the handler function is invoked. Even copying one Hint@ variable into another can take two instructions on most machines.
This means you have to be very careful about what you do in a signal handler. þÂ
• ‰IDX1726Š@�”˜If your handler needs to access any global variables from your program, declare those variables Hvolatile@. This tells the compiler that the value of the variable might change asynchronously, and inhibits certain optimizations that would be invalidated by such modifications.
• ‰IDX1727Š@�”˜If you call a function in the handler, make sure it is Breentrant@ with respect to signals, or else make sure that the signal cannot interrupt a call to a related function.Àð
A function can be non-reentrant if it uses memory that is not on the stack. þÂ
• If a function uses a static variable or a global variable, or a dynamically-allocated object that it finds for itself, then it is non-reentrant and any two calls to the function can interfere. For example, suppose that the signal handler uses Hgethostbyname@. This function returns its value in a static object, reusing the same object each time. If the signal happens to arrive during a call to Hgethostbyname@, or even after one (while the program is still using the value), it will clobber the value that the program asked for. However, if the program does not use Hgethostbyname@ or any other function that returns information in the same object, or if it always blocks signals around each use, then you are safe. There are a large number of library functions that return values in a fixed object, always reusing the same object in this fashion, and all of them cause the same problem. The description of a function in this manual always mentions this behavior.
• If a function uses and modifies an object that you supply, then it is potentially non-reentrant; two calls can interfere if they use the same object. This case arises when you do I/O using streams. Suppose that the signal handler prints a message with Hfprintf@. Suppose that the program was in the middle of an Hfprintf@ call using the same stream when the signal was delivered. Both the signal handler's message and the program's data could be corrupted, because both calls operate on the same data structure--the stream itself. However, if you know that the stream that the handler uses cannot possibly be used by the program at a time when signals can arrive, then you are safe. It is no problem if the program uses some other stream.
• On most systems, Hmalloc@ and Hfree@ are not reentrant, because they use a static data structure which records what memory blocks are free. As a result, no library functions that allocate or free memory are reentrant. This includes functions that allocate space to store a result. The best way to avoid the need to allocate memory in a handler is to allocate in advance space for signal handlers to use. The best way to avoid freeing memory in a handler is to flag or record the objects to be freed, and have the program check from time to time whether anything is waiting to be freed. But this must be done with care, because placing an object on a chain is not atomic, and if it is interrupted by another signal handler that does the same thing, you could "lose" one of the objects. The relocating allocation functions (see section ‰ŠP�”›Relocating Allocator@�”˜) are certainly not safe to use in a signal handler.
• Any function that modifies Herrno@ is non-reentrant, but you can correct for this: in the handler, save the original value of Herrno@ and restore it before returning normally. This prevents errors that occur within the signal handler from being confused with errors from system calls at the point the program is interrupted to run the handler. This technique is generally applicable; if you want to call in a handler a function that modifies a particular object in memory, you can make this safe by saving and restoring that object.
• Merely reading from a memory object is safe provided that you can deal with any of the values that might appear in the object at a time when the signal can be delivered. Keep in mind that assignment to some data types requires more than one instruction, which means that the handler could run "in the middle of" an assignment to the variable if its type is not atomic. See section ‰ŠP�”›Atomic Data Access and Signal Handling@�”˜.
• Merely writing into a memory object is safe as long as a sudden change in the value, at any time when the handler might run, will not disturb anything.Àð
ˆ‰SEC363ŠT�”›Atomic Data Access and Signal Handling

@�”˜Whether the data in your application concerns atoms, or mere text, you have to be careful about the fact that access to a single datum is not necessarily Batomic@. This means that it can take more than one instruction to read or write a single object. In such cases, a signal handler might in the middle of reading or writing the object.
There are three ways you can cope with this problem. You can use data types that are always accessed atomically; you can carefully arrange that nothing untoward happens if an access is interrupted, or you can block all signals around any access that had better not be interrupted (see section ‰ŠP�”›Blocking Signals@�”˜).
ˆ‰SEC364ŠT�”›Problems with Non-Atomic Access

@�”˜Here is an example which shows what can happen if a signal handler runs in the middle of modifying a variable. (Interrupting the reading of a variable can also lead to paradoxical results, but here we only show writing.) #include <signal.h>
#include <stdio.h>

struct two_words { int a, b; } memory;

void
handler(int signum)
{
printf ("%d,%d\n", memory.a, memory.b);
alarm (1);
}

int
main (void)
{
static struct two_words zeros = { 0, 0 }, ones = { 1, 1 };
signal (SIGALRM, handler);
memory = zeros;
alarm (1);
while (1)
{
memory = zeros;
memory = ones;
}
}
This program fills Hmemory@ with zeros, ones, zeros, ones, alternating forever; meanwhile, once per second, the alarm signal handler prints the current contents. (Calling Hprintf@ in the handler is safe in this program because it is certainly not being called outside the handler when the signal happens.)
Clearly, this program can print a pair of zeros or a pair of ones. But that's not all it can do! On most machines, it takes several instructions to store a new value in Hmemory@, and the value is stored one word at a time. If the signal is delivered in between these instructions, the handler might find that Hmemory.a@ is zero and Hmemory.b@ is one (or vice versa).
On some machines it may be possible to store a new value in Hmemory@ with just one instruction that cannot be interrupted. On these machines, the handler will always print two zeros or two ones.
ˆ‰SEC365ŠT�”›Atomic Types

@�”˜To avoid uncertainty about interrupting access to a variable, you can use a particular data type for which access is always atomic: Hsig_atomic_t@. Reading and writing this data type is guaranteed to happen in a single instruction, so there's no way for a handler to run "in the middle" of an access.
The type Hsig_atomic_t@ is always an integer data type, but which one it is, and how many bits it contains, may vary from machine to machine.

AData Type:@ Dsig_atomic_t
Â‰IDX1728Š@�”˜This is an integer data type. Objects of this type are always accessed atomically.À

In practice, you can assume that Hint@ and other integer types no longer than Hint@ are atomic. You can also assume that pointer types are atomic; that is very convenient. Both of these are true on all of the machines that the GNU C library supports, and on all POSIX systems we know of.
ˆ‰SEC366ŠT�”›Atomic Usage Patterns

@�”˜Certain patterns of access avoid any problem even if an access is interrupted. For example, a flag which is set by the handler, and tested and cleared by the main program from time to time, is always safe even if access actually requires two instructions. To show that this is so, we must consider each access that could be interrupted, and show that there is no problem if it is interrupted.
An interrupt in the middle of testing the flag is safe because either it's recognized to be nonzero, in which case the precise value doesn't matter, or it will be seen to be nonzero the next time it's tested.
An interrupt in the middle of clearing the flag is no problem because either the value ends up zero, which is what happens if a signal comes in just before the flag is cleared, or the value ends up nonzero, and subsequent events occur as if the signal had come in just after the flag was cleared. As long as the code handles both of these cases properly, it can also handle a signal in the middle of clearing the flag. (This is an example of the sort of reasoning you need to do to figure out whether non-atomic usage is safe.)
Sometimes you can insure uninterrupted access to one object by protecting its use with another object, perhaps one whose type guarantees atomicity. See section ‰ŠP�”›Signals Close Together Merge into One@�”˜, for an example.
ˆ‰SEC367Št�”›Primitives Interrupted by Signals

@�”˜A signal can arrive and be handled while an I/O primitive such as Hopen@ or Hread@ is waiting for an I/O device. If the signal handler returns, the system faces the question: what should happen next?
POSIX specifies one approach: make the primitive fail right away. The error code for this kind of failure is HEINTR@. This is flexible, but usually inconvenient. Typically, POSIX applications that use signal handlers must check for HEINTR@ after each library function that can return it, in order to try the call again. Often programmers forget to check, which is a common source of error.
The GNU library provides a convenient way to retry a call after a temporary failure, with the macro HTEMP_FAILURE_RETRY@:

AMacro:@ DTEMP_FAILURE_RETRY@ B(Bexpression@)
Â‰IDX1729Š@�”˜This macro evaluates Bexpression@ once. If it fails and reports error code HEINTR@, HTEMP_FAILURE_RETRY@ evaluates it again, and over and over until the result is not a temporary failure.
The value returned by HTEMP_FAILURE_RETRY@ is whatever value Bexpression@ produced.À

BSD avoids HEINTR@ entirely and provides a more convenient approach: to restart the interrupted primitive, instead of making it fail. If you choose this approach, you need not be concerned with HEINTR@.
You can choose either approach with the GNU library. If you use Hsigaction@ to establish a signal handler, you can specify how that handler should behave. If you specify the HSA_RESTART@ flag, return from that handler will resume a primitive; otherwise, return from that handler will cause HEINTR@. See section ‰ŠP�”›Flags for Xsigaction@�”˜.
Another way to specify the choice is with the Hsiginterrupt@ function. See section ‰ŠP�”›BSD Function to Establish a Handler@�”˜.
When you don't specify with Hsigaction@ or Hsiginterrupt@ what a particular handler should do, it uses a default choice. The default choice in the GNU library depends on the feature test macros you have defined. If you define H_BSD_SOURCE@ or H_GNU_SOURCE@ before calling Hsignal@, the default is to resume primitives; otherwise, the default is to make them fail with HEINTR@. (The library contains alternate versions of the Hsignal@ function, and the feature test macros determine which one you really call.) See section ‰ŠP�”›Feature Test Macros@�”˜. ‰IDX1730Š‰IDX1731Š‰IDX1732Š‰IDX1733Š
@�”˜The description of each primitive affected by this issue lists HEINTR@ among the error codes it can return.
There is one situation where resumption never happens no matter which choice you make: when a data-transfer function such as Hread@ or Hwrite@ is interrupted by a signal after transferring part of the data. In this case, the function returns the number of bytes already transferred, indicating partial success.
This might at first appear to cause unreliable behavior on record-oriented devices (including datagram sockets; see section ‰ŠP�”›Datagram Socket Operations@�”˜), where splitting one Hread@ or Hwrite@ into two would read or write two records. Actually, there is no problem, because interruption after a partial transfer cannot happen on such devices; they always transfer an entire record in one burst, with no waiting once data transfer has started.
ˆ‰SEC368Št�”›Generating Signals

‰IDX1734Š‰IDX1735Š‰IDX1736Š
@�”˜Besides signals that are generated as a result of a hardware trap or interrupt, your program can explicitly send signals to itself or to another process.
ˆ‰SEC369ŠT�”›Signaling Yourself

@�”˜A process can send itself a signal with the Hraise@ function. This function is declared in H`signal.h'@. ‰IDX1737Š

A�”˜Function:@ int Draise@ B(int Bsignum@)
Â‰IDX1738Š@�”˜The Hraise@ function sends the signal Bsignum@ to the calling process. It returns zero if successful and a nonzero value if it fails. About the only reason for failure would be if the value of Bsignum@ is invalid.À

AFunction:@ int Dgsignal@ B(int Bsignum@)
Â‰IDX1739Š@�”˜The Hgsignal@ function does the same thing as Hraise@; it is provided only for compatibility with SVID.À

One convenient use for Hraise@ is to reproduce the default behavior of a signal that you have trapped. For instance, suppose a user of your program types the SUSP character (usually HC-z@; see section ‰ŠP�”›Special Characters@�”˜) to send it an interactive stop stop signal (HSIGTSTP@), and you want to clean up some internal data buffers before stopping. You might set this up like this: #include <signal.h>

/* When a stop signal arrives, set the action back to the default
and then resend the signal after doing cleanup actions. */

void
tstp_handler (int sig)
{
signal (SIGTSTP, SIG_DFL);
/* Do cleanup actions here. */
...
raise (SIGTSTP);
}

/* When the process is continued again, restore the signal handler. */

void
cont_handler (int sig)
{
signal (SIGCONT, cont_handler);
signal (SIGTSTP, tstp_handler);
}

/* Enable both handlers during program initialization. */

int
main (void)
{
signal (SIGCONT, cont_handler);
signal (SIGTSTP, tstp_handler);
...
}
DPortability note:@ Hraise@ was invented by the ISO C committee. Older systems may not support it, so using Hkill@ may be more portable. See section ‰ŠP�”›Signaling Another Process@�”˜.
ˆ‰SEC370ŠT�”›Signaling Another Process

‰IDX1740Š@�”˜The Hkill@ function can be used to send a signal to another process. In spite of its name, it can be used for a lot of things other than causing a process to terminate. Some examples of situations where you might want to send signals between processes are: þÂ
• A parent process starts a child to perform a task--perhaps having the child running an infinite loop--and then terminates the child when the task is no longer needed.
• A process executes as part of a group, and needs to terminate or notify the other processes in the group when an error or other event occurs.
• Two processes need to synchronize while working together.Àð
This section assumes that you know a little bit about how processes work. For more information on this subject, see section ‰ŠP�”›Processes@�”˜.
The Hkill@ function is declared in H`signal.h'@. ‰IDX1741Š

A�”˜Function:@ int Dkill@ B(pid_t Bpid@, int Bsignum@)
Â‰IDX1742Š@�”˜The Hkill@ function sends the signal Bsignum@ to the process or process group specified by Bpid@. Besides the signals listed in section ‰ŠP�”›Standard Signals@�”˜, Bsignum@ can also have a value of zero to check the validity of the Bpid@.
The Bpid@ specifies the process or process group to receive the signal:
JpidH > 0
Ä@The process whose identifier is Bpid@.
ÂJpidH == 0
Ä@All processes in the same process group as the sender.
ÂJpidH < -1
Ä@The process group whose identifier is -Bpid@.
ÂJpidH == -1
Ä@If the process is privileged, send the signal to all processes except for some special system processes. Otherwise, send the signal to all processes with the same effective user ID.Â

A process can send a signal Bsignum@ to itself with a call like Hkill (getpid(), JsignumH)@. If Hkill@ is used by a process to send a signal to itself, and the signal is not blocked, then Hkill@ delivers at least one signal (which might be some other pending unblocked signal instead of the signal Bsignum@) to that process before it returns.
The return value from Hkill@ is zero if the signal can be sent successfully. Otherwise, no signal is sent, and a value of H-1@ is returned. If Bpid@ specifies sending a signal to several processes, Hkill@ succeeds if it can send the signal to at least one of them. There's no way you can tell which of the processes got the signal or whether all of them did.
The following Herrno@ error conditions are defined for this function:
HEINVAL
Ä@The Bsignum@ argument is an invalid or unsupported number.
ÂHEPERM
Ä@You do not have the privilege to send a signal to the process or any of the processes in the process group named by Bpid@.
ÂHESCRH
Ä@The Bpid@ argument does not refer to an existing process or group.Â
À

AFunction:@ int Dkillpg@ B(int Bpgid@, int Bsignum@)
Â‰IDX1743Š@�”˜This is similar to Hkill@, but sends signal Bsignum@ to the process group Bpgid@. This function is provided for compatibility with BSD; using Hkill@ to do this is more portable.À

As a simple example of Hkill@, the call Hkill (getpid (), JsigH)@ has the same effect as Hraise (JsigH)@.
ˆ‰SEC371ŠT�”›Permission for using \kill

@�”˜There are restrictions that prevent you from using Hkill@ to send signals to any random process. These are intended to prevent antisocial behavior such as arbitrarily killing off processes belonging to another user. In typical use, Hkill@ is used to pass signals between parent, child, and sibling processes, and in these situations you normally do have permission to send signals. The only common exception is when you run a setuid program in a child process; if the program changes its real UID as well as its effective UID, you may not have permission to send a signal. The Hsu@ program does this.
Whether a process has permission to send a signal to another process is determined by the user IDs of the two processes. This concept is discussed in detail in section ‰ŠP�”›The Persona of a Process@�”˜.
Generally, for a process to be able to send a signal to another process, either the sending process must belong to a privileged user (like H`root'@), or the real or effective user ID of the sending process must match the real or effective user ID of the receiving process. If the receiving process has changed its effective user ID from the set-user-ID mode bit on its process image file, then the owner of the process image file is used in place of its current effective user ID. In some implementations, a parent process might be able to send signals to a child process even if the user ID's don't match, and other implementations might enforce other restrictions.
The HSIGCONT@ signal is a special case. It can be sent if the sender is part of the same session as the receiver, regardless of user IDs.
ˆ‰SEC372ŠT�”›Using \killT for Communication

‰IDX1744Š@�”˜Here is a longer example showing how signals can be used for interprocess communication. This is what the HSIGUSR1@ and HSIGUSR2@ signals are provided for. Since these signals are fatal by default, the process that is supposed to receive them must trap them through Hsignal@ or Hsigaction@.
In this example, a parent process forks a child process and then waits for the child to complete its initialization. The child process tells the parent when it is ready by sending it a HSIGUSR1@ signal, using the Hkill@ function. #include <signal.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

/* When a HSIGUSR1@ signal arrives, set this variable. */
volatile sig_atomic_t usr_interrupt = 0;

void
synch_signal (int sig)
{
usr_interrupt = 1;
}

/* The child process executes this function. */
void
child_function (void)
{
/* Perform initialization. */
printf ("I'm here!!! My pid is %d.\n", (int) getpid ());

/* Let parent know you're done. */
kill (getppid (), SIGUSR1);

/* Continue with execution. */
puts ("Bye, now....");
exit (0);
}

int
main (void)
{
struct sigaction usr_action;
sigset_t block_mask;
pid_t child_id;

/* Establish the signal handler. */
sigfillset (&block_mask);
usr_action.sa_handler = synch_signal;
usr_action.sa_mask = block_mask;
usr_action.sa_flags = 0;
sigaction (SIGUSR1, &usr_action, NULL);

/* Create the child process. */
child_id = fork ();
if (child_id == 0)
child_function (); /* Does not return. */

/* Busy wait for the child to send a signal. */
while (!usr_interrupt)
;

/* Now continue execution. */
puts ("That's all, folks!");

return 0;
}
This example uses a busy wait, which is bad, because it wastes CPU cycles that other programs could otherwise use. It is better to ask the system to wait until the signal arrives. See the example in section ‰ŠP�”›Waiting for a Signal@�”˜.
ˆ‰SEC373Št�”›Blocking Signals

‰IDX1745Š
@�”˜Blocking a signal means telling the operating system to hold it and deliver it later. Generally, a program does not block signals indefinitely--it might as well ignore them by setting their actions to HSIG_IGN@. But it is useful to block signals briefly, to prevent them from interrupting sensitive operations. For instance: þÂ
• You can use the Hsigprocmask@ function to block signals while you modify global variables that are also modified by the handlers for these signals.
• You can set Hsa_mask@ in your Hsigaction@ call to block certain signals while a particular signal handler runs. This way, the signal handler can run without being interrupted itself by signals.Àð
ˆ‰SEC374ŠT�”›Why Blocking Signals is Useful

@�”˜Temporary blocking of signals with Hsigprocmask@ gives you a way to prevent interrupts during critical parts of your code. If signals arrive in that part of the program, they are delivered later, after you unblock them.
One example where this is useful is for sharing data between a signal handler and the rest of the program. If the type of the data is not Hsig_atomic_t@ (see section ‰ŠP�”›Atomic Data Access and Signal Handling@�”˜), then the signal handler could run when the rest of the program has only half finished reading or writing the data. This would lead to confusing consequences.
To make the program reliable, you can prevent the signal handler from running while the rest of the program is examining or modifying that data--by blocking the appropriate signal around the parts of the program that touch the data.
Blocking signals is also necessary when you want to perform a certain action only if a signal has not arrived. Suppose that the handler for the signal sets a flag of type Hsig_atomic_t@; you would like to test the flag and perform the action if the flag is not set. This is unreliable. Suppose the signal is delivered immediately after you test the flag, but before the consequent action: then the program will perform the action even though the signal has arrived.
The only way to test reliably for whether a signal has yet arrived is to test while the signal is blocked.
ˆ‰SEC375ŠT�”›Signal Sets

@�”˜All of the signal blocking functions use a data structure called a Bsignal set@ to specify what signals are affected. Thus, every activity involves two stages: creating the signal set, and then passing it as an argument to a library function. ‰IDX1746Š
@�”˜These facilities are declared in the header file H`signal.h'@. ‰IDX1747Š

A�”˜Data Type:@ Dsigset_t
Â‰IDX1748Š@�”˜The Hsigset_t@ data type is used to represent a signal set. Internally, it may be implemented as either an integer or structure type.
For portability, use only the functions described in this section to initialize, change, and retrieve information from Hsigset_t@ objects--don't try to manipulate them directly.À

There are two ways to initialize a signal set. You can initially specify it to be empty with Hsigemptyset@ and then add specified signals individually. Or you can specify it to be full with Hsigfillset@ and then delete specified signals individually.
You must always initialize the signal set with one of these two functions before using it in any other way. Don't try to set all the signals explicitly because the Hsigset_t@ object might include some other information (like a version field) that needs to be initialized as well. (In addition, it's not wise to put into your program an assumption that the system has no signals aside from the ones you know about.)

AFunction:@ int Dsigemptyset@ B(sigset_t *Bset@)
Â‰IDX1749Š@�”˜This function initializes the signal set Bset@ to exclude all of the defined signals. It always returns H0@.À

AFunction:@ int Dsigfillset@ B(sigset_t *Bset@)
Â‰IDX1750Š@�”˜This function initializes the signal set Bset@ to include all of the defined signals. Again, the return value is H0@.À

AFunction:@ int Dsigaddset@ B(sigset_t *Bset@, int Bsignum@)
Â‰IDX1751Š@�”˜This function adds the signal Bsignum@ to the signal set Bset@. All Hsigaddset@ does is modify Bset@; it does not block or unblock any signals.
The return value is H0@ on success and H-1@ on failure. The following Herrno@ error condition is defined for this function:
HEINVAL
Ä@The Bsignum@ argument doesn't specify a valid signal.Â
À

AFunction:@ int Dsigdelset@ B(sigset_t *Bset@, int Bsignum@)
Â‰IDX1752Š@�”˜This function removes the signal Bsignum@ from the signal set Bset@. All Hsigdelset@ does is modify Bset@; it does not block or unblock any signals. The return value and error conditions are the same as for Hsigaddset@.À

Finally, there is a function to test what signals are in a signal set:

AFunction:@ int Dsigismember@ B(const sigset_t *Bset@, int Bsignum@)
Â‰IDX1753Š@�”˜The Hsigismember@ function tests whether the signal Bsignum@ is a member of the signal set Bset@. It returns H1@ if the signal is in the set, H0@ if not, and H-1@ if there is an error.
The following Herrno@ error condition is defined for this function:
HEINVAL
Ä@The Bsignum@ argument doesn't specify a valid signal.Â
À

ˆ‰SEC376ŠT�”›Process Signal Mask

‰IDX1754Š‰IDX1755Š
@�”˜The collection of signals that are currently blocked is called the Bsignal mask@. Each process has its own signal mask. When you create a new process (see section ‰ŠP�”›Creating a Process@�”˜), it inherits its parent's mask. You can block or unblock signals with total flexibility by modifying the signal mask.
The prototype for the Hsigprocmask@ function is in H`signal.h'@. ‰IDX1756Š

A�”˜Function:@ int Dsigprocmask@ B(int Bhow@, const sigset_t *Bset@, sigset_t *Boldset@)
Â‰IDX1757Š@�”˜The Hsigprocmask@ function is used to examine or change the calling process's signal mask. The Bhow@ argument determines how the signal mask is changed, and must be one of the following values:
HSIG_BLOCK
Ä‰IDX1758Š@�”˜Block the signals in Hset@---add them to the existing mask. In other words, the new mask is the union of the existing mask and Bset@. ‰IDX1759Š
ÂH�”˜SIG_UNBLOCK
Ä@Unblock the signals in Bset@---remove them from the existing mask. ‰IDX1760Š
ÂH�”˜SIG_SETMASK
Ä@Use Bset@ for the mask; ignore the previous value of the mask.Â

The last argument, Boldset@, is used to return information about the old process signal mask. If you just want to change the mask without looking at it, pass a null pointer as the Boldset@ argument. Similarly, if you want to know what's in the mask without changing it, pass a null pointer for Bset@ (in this case the Bhow@ argument is not significant). The Boldset@ argument is often used to remember the previous signal mask in order to restore it later. (Since the signal mask is inherited over Hfork@ and Hexec@ calls, you can't predict what its contents are when your program starts running.)
If invoking Hsigprocmask@ causes any pending signals to be unblocked, at least one of those signals is delivered to the process before Hsigprocmask@ returns. The order in which pending signals are delivered is not specified, but you can control the order explicitly by making multiple Hsigprocmask@ calls to unblock various signals one at a time.
The Hsigprocmask@ function returns H0@ if successful, and H-1@ to indicate an error. The following Herrno@ error conditions are defined for this function:
HEINVAL
Ä@The Bhow@ argument is invalid.Â

You can't block the HSIGKILL@ and HSIGSTOP@ signals, but if the signal set includes these, Hsigprocmask@ just ignores them instead of returning an error status.
Remember, too, that blocking program error signals such as HSIGFPE@ leads to undesirable results for signals generated by an actual program error (as opposed to signals sent with Hraise@ or Hkill@). This is because your program may be too broken to be able to continue executing to a point where the signal is unblocked again. See section ‰ŠP�”›Program Error Signals@�”˜.À

ˆ‰SEC377ŠT�”›Blocking to Test for Delivery of a Signal

@�”˜Now for a simple example. Suppose you establish a handler for HSIGALRM@ signals that sets a flag whenever a signal arrives, and your main program checks this flag from time to time and then resets it. You can prevent additional HSIGALRM@ signals from arriving in the meantime by wrapping the critical part of the code with calls to Hsigprocmask@, like this: /* This variable is set by the SIGALRM signal handler. */
volatile sig_atomic_t flag = 0;

int
main (void)
{
sigset_t block_alarm;

...

/* Initialize the signal mask. */
sigemptyset (&block_alarm);
sigaddset (&block_alarm, SIGALRM);

while (1)
{
/* Check if a signal has arrived; if so, reset the flag. */
sigprocmask (SIG_BLOCK, &block_alarm, NULL);
if (flag)
{
Bactions-if-not-arrived
@ flag = 0;
}
sigprocmask (SIG_UNBLOCK, &block_alarm, NULL);

...
}
}
ˆ‰SEC378ŠT�”›Blocking Signals for a Handler

‰IDX1761Š
@�”˜When a signal handler is invoked, you usually want it to be able to finish without being interrupted by another signal. From the moment the handler starts until the moment it finishes, you must block signals that might confuse it or corrupt its data.
When a handler function is invoked on a signal, that signal is automatically blocked (in addition to any other signals that are already in the process's signal mask) during the time the handler is running. If you set up a handler for HSIGTSTP@, for instance, then the arrival of that signal forces further HSIGTSTP@ signals to wait during the execution of the handler.
However, by default, other kinds of signals are not blocked; they can arrive during handler execution.
The reliable way to block other kinds of signals during the execution of the handler is to use the Hsa_mask@ member of the Hsigaction@ structure.
Here is an example: #include <signal.h>
#include <stddef.h>

void catch_stop ();

void
install_handler (void)
{
struct sigaction setup_action;
sigset_t block_mask;

sigemptyset (&block_mask);
/* Block other terminal-generated signals while handler runs. */
sigaddset (&block_mask, SIGINT);
sigaddset (&block_mask, SIGQUIT);
setup_action.sa_handler = catch_stop;
setup_action.sa_mask = block_mask;
setup_action.sa_flags = 0;
sigaction (SIGTSTP, &setup_action, NULL);
}
This is more reliable than blocking the other signals explicitly in the code for the handler. If you block signals explicitly in the handler, you can't avoid at least a short interval at the beginning of the handler where they are not yet blocked.
You cannot remove signals from the process's current mask using this mechanism. However, you can make calls to Hsigprocmask@ within your handler to block or unblock signals as you wish.
In any case, when the handler returns, the system restores the mask that was in place before the handler was entered. If any signals that become unblocked by this restoration are pending, the process will receive those signals immediately, before returning to the code that was interrupted.
ˆ‰SEC379ŠT�”›Checking for Pending Signals

‰IDX1762Š‰IDX1763Š‰IDX1764Š
@�”˜You can find out which signals are pending at any time by calling Hsigpending@. This function is declared in H`signal.h'@. ‰IDX1765Š

A�”˜Function:@ int Dsigpending@ B(sigset_t *Bset@)
Â‰IDX1766Š@�”˜The Hsigpending@ function stores information about pending signals in Bset@. If there is a pending signal that is blocked from delivery, then that signal is a member of the returned set. (You can test whether a particular signal is a member of this set using Hsigismember@; see section ‰ŠP�”›Signal Sets@�”˜.)
The return value is H0@ if successful, and H-1@ on failure.À

Testing whether a signal is pending is not often useful. Testing when that signal is not blocked is almost certainly bad design.
Here is an example. #include <signal.h>
#include <stddef.h>

sigset_t base_mask, waiting_mask;

sigemptyset (&base_mask);
sigaddset (&base_mask, SIGINT);
sigaddset (&base_mask, SIGTSTP);

/* Block user interrupts while doing other processing. */
sigprocmask (SIG_SETMASK, &base_mask, NULL);
...

/* After a while, check to see whether any signals are pending. */
sigpending (&waiting_mask);
if (sigismember (&waiting_mask, SIGINT)) {
/* User has tried to kill the process. */
}
else if (sigismember (&waiting_mask, SIGTSTP)) {
/* User has tried to stop the process. */
}
Remember that if there is a particular signal pending for your process, additional signals of that same type that arrive in the meantime might be discarded. For example, if a HSIGINT@ signal is pending when another HSIGINT@ signal arrives, your program will probably only see one of them when you unblock this signal.
DPortability Note:@ The Hsigpending@ function is new in POSIX.1. Older systems have no equivalent facility.
ˆ‰SEC380ŠT�”›Remembering a Signal to Act On Later

@�”˜Instead of blocking a signal using the library facilities, you can get almost the same results by making the handler set a flag to be tested later, when you "unblock". Here is an example: /* If this flag is nonzero, don't handle the signal right away. */
volatile sig_atomic_t signal_pending;

/* This is nonzero if a signal arrived and was not handled. */
volatile sig_atomic_t defer_signal;

void
handler (int signum)
{
if (defer_signal)
signal_pending = signum;
else
... /* ``Really'' handle the signal. */
}

...

void
update_mumble (int frob)
{
/* Prevent signals from having immediate effect. */
defer_signal++;
/* Now update Hmumble@, without worrying about interruption. */
mumble.a = 1;
mumble.b = hack ();
mumble.c = frob;
/* We have updated Hmumble@. Handle any signal that came in. */
defer_signal--;
if (defer_signal == 0 && signal_pending != 0)
raise (signal_pending);
}
Note how the particular signal that arrives is stored in Hsignal_pending@. That way, we can handle several types of inconvenient signals with the same mechanism.
We increment and decrement Hdefer_signal@ so that nested critical sections will work properly; thus, if Hupdate_mumble@ were called with Hsignal_pending@ already nonzero, signals would be deferred not only within Hupdate_mumble@, but also within the caller. This is also why we do not check Hsignal_pending@ if Hdefer_signal@ is still nonzero.
The incrementing and decrementing of Hdefer_signal@ require more than one instruction; it is possible for a signal to happen in the middle. But that does not cause any problem. If the signal happens early enough to see the value from before the increment or decrement, that is equivalent to a signal which came before the beginning of the increment or decrement, which is a case that works properly.
It is absolutely vital to decrement Hdefer_signal@ before testing Hsignal_pending@, because this avoids a subtle bug. If we did these things in the other order, like this, if (defer_signal == 1 && signal_pending != 0)
raise (signal_pending);
defer_signal--;
then a signal arriving in between the Hif@ statement and the decrement would be effectively "lost" for an indefinite amount of time. The handler would merely set Hdefer_signal@, but the program having already tested this variable, it would not test the variable again.
‰IDX1767Š@�”˜Bugs like these are called Btiming errors@. They are especially bad because they happen only rarely and are nearly impossible to reproduce. You can't expect to find them with a debugger as you would find a reproducible bug. So it is worth being especially careful to avoid them.
(You would not be tempted to write the code in this order, given the use of Hdefer_signal@ as a counter which must be tested along with Hsignal_pending@. After all, testing for zero is cleaner than testing for one. But if you did not use Hdefer_signal@ as a counter, and gave it values of zero and one only, then either order might seem equally simple. This is a further advantage of using a counter for Hdefer_signal@: it will reduce the chance you will write the code in the wrong order and create a subtle bug.)
ˆ‰SEC381Št�”›Waiting for a Signal

‰IDX1768Š‰IDX1769Š
@�”˜If your program is driven by external events, or uses signals for synchronization, then when it has nothing to do it should probably wait until a signal arrives.
ˆ‰SEC382ŠT�”›Using \pause

@�”˜The simple way to wait until a signal arrives is to call Hpause@. Please read about its disadvantages, in the following section, before you use it.

AFunction:@ int Dpause@ B()
Â‰IDX1770Š@�”˜The Hpause@ function suspends program execution until a signal arrives whose action is either to execute a handler function, or to terminate the process.
If the signal causes a handler function to be executed, then Hpause@ returns. This is considered an unsuccessful return (since "successful" behavior would be to suspend the program forever), so the return value is H-1@. Even if you specify that other primitives should resume when a system handler returns (see section ‰ŠP�”›Primitives Interrupted by Signals@�”˜), this has no effect on Hpause@; it always fails when a signal is handled.
The following Herrno@ error conditions are defined for this function:
HEINTR
Ä@The function was interrupted by delivery of a signal.Â

If the signal causes program termination, Hpause@ doesn't return (obviously).
The Hpause@ function is declared in H`unistd.h'@.À

ˆ‰SEC383ŠT�”›Problems with \pause

@�”˜The simplicity of Hpause@ can conceal serious timing errors that can make a program hang mysteriously.
It is safe to use Hpause@ if the real work of your program is done by the signal handlers themselves, and the "main program" does nothing but call Hpause@. Each time a signal is delivered, the handler will do the next batch of work that is to be done, and then return, so that the main loop of the program can call Hpause@ again.
You can't safely use Hpause@ to wait until one more signal arrives, and then resume real work. Even if you arrange for the signal handler to cooperate by setting a flag, you still can't use Hpause@ reliably. Here is an example of this problem: /* Husr_interrupt@ is set by the signal handler. */
if (!usr_interrupt)
pause ();

/* Do work once the signal arrives. */
...
This has a bug: the signal could arrive after the variable Husr_interrupt@ is checked, but before the call to Hpause@. If no further signals arrive, the process would never wake up again.
You can put an upper limit on the excess waiting by using Hsleep@ in a loop, instead of using Hpause@. (See section ‰ŠP�”›Sleeping@�”˜, for more about Hsleep@.) Here is what this looks like: /* Husr_interrupt@ is set by the signal handler.
while (!usr_interrupt)
sleep (1);

/* Do work once the signal arrives. */
...
For some purposes, that is good enough. But with a little more complexity, you can wait reliably until a particular signal handler is run, using Hsigsuspend@.
ˆ‰SEC384ŠT�”›Using \sigsuspend

@�”˜The clean and reliable way to wait for a signal to arrive is to block it and then use Hsigsuspend@. By using Hsigsuspend@ in a loop, you can wait for certain kinds of signals, while letting other kinds of signals be handled by their handlers.

AFunction:@ int Dsigsuspend@ B(const sigset_t *Bset@)
Â‰IDX1771Š@�”˜This function replaces the process's signal mask with Bset@ and then suspends the process until a signal is delivered whose action is either to terminate the process or invoke a signal handling function. In other words, the program is effectively suspended until one of the signals that is not a member of Bset@ arrives.
If the process is woken up by deliver of a signal that invokes a handler function, and the handler function returns, then Hsigsuspend@ also returns.
The mask remains Bset@ only as long as Hsigsuspend@ is waiting. The function Hsigsuspend@ always restores the previous signal mask when it returns.
The return value and error conditions are the same as for Hpause@.À

With Hsigsuspend@, you can replace the Hpause@ or Hsleep@ loop in the previous section with something completely reliable: sigset_t mask, oldmask;

...

/* Set up the mask of signals to temporarily block. */
sigemptyset (&mask);
sigaddset (&mask, SIGUSR1);

...

/* Wait for a signal to arrive. */
sigprocmask (SIG_BLOCK, &mask, &oldmask);
while (!usr_interrupt)
sigsuspend (&oldmask);
sigprocmask (SIG_UNBLOCK, &mask, NULL);
This last piece of code is a little tricky. The key point to remember here is that when Hsigsuspend@ returns, it resets the process's signal mask to the original value, the value from before the call to Hsigsuspend@---in this case, the HSIGUSR1@ signal is once again blocked. The second call to Hsigprocmask@ is necessary to explicitly unblock this signal.
One other point: you may be wondering why the Hwhile@ loop is necessary at all, since the program is apparently only waiting for one HSIGUSR1@ signal. The answer is that the mask passed to Hsigsuspend@ permits the process to be woken up by the delivery of other kinds of signals, as well--for example, job control signals. If the process is woken up by a signal that doesn't set Husr_interrupt@, it just suspends itself again until the "right" kind of signal eventually arrives.
This technique takes a few more lines of preparation, but that is needed just once for each kind of wait criterion you want to use. The code that actually waits is just four lines.
ˆ‰SEC385Št�”›Using a Separate Signal Stack

@�”˜A signal stack is a special area of memory to be used as the execution stack during signal handlers. It should be fairly large, to avoid any danger that it will overflow in turn; the macro HSIGSTKSZ@ is defined to a canonical size for signal stacks. You can use Hmalloc@ to allocate the space for the stack. Then call Hsigaltstack@ or Hsigstack@ to tell the system to use that space for the signal stack.
You don't need to write signal handlers differently in order to use a signal stack. Switching from one stack to the other happens automatically. (Some non-GNU debuggers on some machines may get confused if you examine a stack trace while a handler that uses the signal stack is running.)
There are two interfaces for telling the system to use a separate signal stack. Hsigstack@ is the older interface, which comes from 4.2 BSD. Hsigaltstack@ is the newer interface, and comes from 4.4 BSD. The Hsigaltstack@ interface has the advantage that it does not require your program to know which direction the stack grows, which depends on the specific machine and operating system.

AData Type:@ Dstruct sigaltstack
Â‰IDX1772Š@�”˜This structure describes a signal stack. It contains the following members:
Hvoid *ss_sp
Ä@This points to the base of the signal stack.
ÂHsize_t ss_size
Ä@This is the size (in bytes) of the signal stack which H`ss_sp'@ points to. You should set this to however much space you allocated for the stack. There are two macros defined in H`signal.h'@ that you should use in calculating this size:
HSIGSTKSZ
Æ‰IDX1773Š@�”˜This is the canonical size for a signal stack. It is judged to be sufficient for normal uses.
ÄHMINSIGSTKSZ
Æ‰IDX1774Š@�”˜This is the amount of signal stack space the operating system needs just to implement signal delivery. The size of a signal stack Dmust@ be greater than this. For most cases, just using HSIGSTKSZ@ for Hss_size@ is sufficient. But if you know how much stack space your program's signal handlers will need, you may want to use a different size. In this case, you should allocate HMINSIGSTKSZ@ additional bytes for the signal stack and increase Hss_size@ accordingly.Ä

ÂHint ss_flags
Ä@This field contains the bitwise OR of these flags:
HSA_DISABLE
Æ‰IDX1775Š@�”˜This tells the system that it should not use the signal stack.
ÄHSA_ONSTACK
Æ‰IDX1776Š@�”˜This is set by the system, and indicates that the signal stack is currently in use. If this bit is not set, then signals will be delivered on the normal user stack.Ä
Â
À

AFunction:@ int Dsigaltstack@ B(const struct sigaltstack *Bstack@, struct sigaltstack *Boldstack@)
Â‰IDX1777Š@�”˜The Hsigaltstack@ function specifies an alternate stack for use during signal handling. When a signal is received by the process and its action indicates that the signal stack is used, the system arranges a switch to the currently installed signal stack while the handler for that signal is executed.
If Boldstack@ is not a null pointer, information about the currently installed signal stack is returned in the location it points to. If Bstack@ is not a null pointer, then this is installed as the new stack for use by signal handlers.
The return value is H0@ on success and H-1@ on failure. If Hsigaltstack@ fails, it sets Herrno@ to one of these values:

Ä
ÂHEINVAL
Ä@You tried to disable a stack that was in fact currently in use.
ÂHENOMEM
Ä@The size of the alternate stack was too small. It must be greater than HMINSIGSTKSZ@.Â
À

Here is the older Hsigstack@ interface. You should use Hsigaltstack@ instead on systems that have it.

AData Type:@ Dstruct sigstack
Â‰IDX1778Š@�”˜This structure describes a signal stack. It contains the following members:
Hvoid *ss_sp
Ä@This is the stack pointer. If the stack grows downwards on your machine, this should point to the top of the area you allocated. If the stack grows upwards, it should point to the bottom.
ÂHint ss_onstack
Ä@This field is true if the process is currently using this stack.Â
À

AFunction:@ int Dsigstack@ B(const struct sigstack *Bstack@, struct sigstack *Boldstack@)
Â‰IDX1779Š@�”˜The Hsigstack@ function specifies an alternate stack for use during signal handling. When a signal is received by the process and its action indicates that the signal stack is used, the system arranges a switch to the currently installed signal stack while the handler for that signal is executed.
If Boldstack@ is not a null pointer, information about the currently installed signal stack is returned in the location it points to. If Bstack@ is not a null pointer, then this is installed as the new stack for use by signal handlers.
The return value is H0@ on success and H-1@ on failure.À

ˆ‰SEC386Št�”›BSD Signal Handling

@�”˜This section describes alternative signal handling functions derived from BSD Unix. These facilities were an advance, in their time; today, they are mostly obsolete, and supported mainly for compatibility with BSD Unix.
There are many similarities between the BSD and POSIX signal handling facilities, because the POSIX facilities were inspired by the BSD facilities. Besides having different names for all the functions to avoid conflicts, the main differences between the two are: þÂ
• BSD Unix represents signal masks as an Hint@ bit mask, rather than as a Hsigset_t@ object.
• The BSD facilities use a different default for whether an interrupted primitive should fail or resume. The POSIX facilities make system calls fail unless you specify that they should resume. With the BSD facility, the default is to make system calls resume unless you say they should fail. See section ‰ŠP�”›Primitives Interrupted by Signals@�”˜.Àð
The BSD facilities are declared in H`signal.h'@. ‰IDX1780Š
ˆ‰SEC387ŠT�”›BSD Function to Establish a Handler

A�”˜Data Type:@ Dstruct sigvec
Â‰IDX1781Š@�”˜This data type is the BSD equivalent of Hstruct sigaction@ (see section ‰ŠP�”›Advanced Signal Handling@�”˜); it is used to specify signal actions to the Hsigvec@ function. It contains the following members:
Hsighandler_t sv_handler
Ä@This is the handler function.
ÂHint sv_mask
Ä@This is the mask of additional signals to be blocked while the handler function is being called.
ÂHint sv_flags
Ä@This is a bit mask used to specify various flags which affect the behavior of the signal. You can also refer to this field as Hsv_onstack@.Â
À

These symbolic constants can be used to provide values for the Hsv_flags@ field of a Hsigvec@ structure. This field is a bit mask value, so you bitwise-OR the flags of interest to you together.

AMacro:@ int DSV_ONSTACK
Â‰IDX1782Š@�”˜If this bit is set in the Hsv_flags@ field of a Hsigvec@ structure, it means to use the signal stack when delivering the signal.À

AMacro:@ int DSV_INTERRUPT
Â‰IDX1783Š@�”˜If this bit is set in the Hsv_flags@ field of a Hsigvec@ structure, it means that system calls interrupted by this kind of signal should not be restarted if the handler returns; instead, the system calls should return with a HEINTR@ error status. See section ‰ŠP�”›Primitives Interrupted by Signals@�”˜.À

AMacro:@ int DSV_RESETHAND
Â‰IDX1784Š@�”˜If this bit is set in the Hsv_flags@ field of a Hsigvec@ structure, it means to reset the action for the signal back to HSIG_DFL@ when the signal is received.À

AFunction:@ int Dsigvec@ B(int Bsignum@, const struct sigvec *Baction@,struct sigvec *Bold-action@)
Â‰IDX1785Š@�”˜This function is the equivalent of Hsigaction@ (see section ‰ŠP�”›Advanced Signal Handling@�”˜); it installs the action Baction@ for the signal Bsignum@, returning information about the previous action in effect for that signal in Bold-action@.À

AFunction:@ int Dsiginterrupt@ B(int Bsignum@, int Bfailflag@)
Â‰IDX1786Š@�”˜This function specifies which approach to use when certain primitives are interrupted by handling signal Bsignum@. If Bfailflag@ is false, signal Bsignum@ restarts primitives. If Bfailflag@ is true, handling Bsignum@ causes these primitives to fail with error code HEINTR@. See section ‰ŠP�”›Primitives Interrupted by Signals@�”˜.À

ˆ‰SEC388ŠT�”›BSD Functions for Blocking Signals

A�”˜Macro:@ int Dsigmask@ B(int Bsignum@)
Â‰IDX1787Š@�”˜This macro returns a signal mask that has the bit for signal Bsignum@ set. You can bitwise-OR the results of several calls to Hsigmask@ together to specify more than one signal. For example, (sigmask (SIGTSTP) | sigmask (SIGSTOP)
| sigmask (SIGTTIN) | sigmask (SIGTTOU))
specifies a mask that includes all the job-control stop signals.À

AFunction:@ int Dsigblock@ B(int Bmask@)
Â‰IDX1788Š@�”˜This function is equivalent to Hsigprocmask@ (see section ‰ŠP�”›Process Signal Mask@�”˜) with a Bhow@ argument of HSIG_BLOCK@: it adds the signals specified by Bmask@ to the calling process's set of blocked signals. The return value is the previous set of blocked signals.À

AFunction:@ int Dsigsetmask@ B(int Bmask@)
Â‰IDX1789Š@�”˜This function equivalent to Hsigprocmask@ (see section ‰ŠP�”›Process Signal Mask@�”˜) with a Bhow@ argument of HSIG_SETMASK@: it sets the calling process's signal mask to Bmask@. The return value is the previous set of blocked signals.À

AFunction:@ int Dsigpause@ B(int Bmask@)
Â‰IDX1790Š@�”˜This function is the equivalent of Hsigsuspend@ (see section ‰ŠP�”›Waiting for a Signal@�”˜): it sets the calling process's signal mask to Bmask@, and waits for a signal to arrive. On return the previous set of blocked signals is restored.À

Œ
Go to the ‰ŠP�”›first@�”˜, ‰ŠP�”›previous@�”˜, ‰ŠP�”›next@�”˜, ‰ŠP�”›last@�”˜ section, ‰ŠP�”›table of contents@�”˜.