Signal Handling--ref

signalis 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.

generate,orraise) 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 typingC-z,or terminate it withC-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 tokillorraiseby the same process.
• A call tokillfrom 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),and reading or writing to a terminal in certain situations (see section).

killandraise) generates its own particular kind of signal. The various kinds of signals are listed and described in detail in section.

openreturns-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.

killwhose purpose is specifically to generate a signal.

synchronouslyorasynchronously. 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.

pending. Normally it remains pending for just a short period of time and then isdeliveredto the process that was signaled. However,if that kind of signal is currentlyblocked,it may remain pending indefinitely--until signals of that kind areunblocked. Once unblocked,it will be delivered immediately. See section.

specified actionfor that signal is taken. For certain signals,such asSIGKILLandSIGSTOP,the action is fixed,but for most signals,the program has a choice: ignore the signal,specify ahandler function,or accept thedefault actionfor that kind of signal. The program specifies its choice using functions such assignalorsigaction(see section). We sometimes say that a handlercatchesthe signal. While the handler is running,that particular signal is normally blocked.

default actiontakes place. Each kind of signal has its own default action,documented below (see section). 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.

waitorwaitpidfunctions. (This is discussed in more detail in section.) 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.

core dump filewhich 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.

signal numberfor 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.

`signal.h'.

intNSIG

The value of this symbolic constant is the total number of signals defined. Since the signal numbers are allocated consecutively,NSIGis also one greater than the largest defined signal number.

.)

longjmpto return control to the command level.

raiseorkillinstead of a real error.

core dump filewhich records the state of the process at the time of termination. The core dump file is named`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 variableCOREFILE.) The purpose of core dump files is so that you can examine them with a debugger to investigate what caused the error.

intSIGFPE

TheSIGFPEsignal 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.

Actual floating-point exceptions are a complicated subject because there are many types of exceptions with subtly different meanings,and theSIGFPEsignal doesn't distinguish between them. TheIEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985)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.

SIGFPEhandler 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).

FPE_INTOVF_TRAP

Integer overflow (impossible in a C program unless you enable overflow trapping in a hardware-specific fashion).

FPE_INTDIV_TRAP

Integer division by zero.

FPE_SUBRNG_TRAP

Subscript-range (something that C programs never check for).

FPE_FLTOVF_TRAP

Floating overflow trap.

FPE_FLTDIV_TRAP

Floating/decimal division by zero.

FPE_FLTUND_TRAP

Floating underflow trap. (Trapping on floating underflow is not normally enabled.)

FPE_DECOVF_TRAP

Decimal overflow trap. (Only a few machines have decimal arithmetic and C never uses it.)

intSIGILL

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,SIGILLtypically 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.

SIGILLcan also be generated when the stack overflows,or when the system has trouble running the handler for a signal.

intSIGSEGV

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 aSIGSEGVcondition 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 generatesSIGSEGVorSIGBUS.

intSIGBUS

This signal is generated when an invalid pointer is dereferenced. LikeSIGSEGV,this signal is typically the result of dereferencing an uninitialized pointer. The difference between the two is thatSIGSEGVindicates an invalid access to valid memory,whileSIGBUSindicates an access to an invalid address. In particular,SIGBUSsignals 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".

intSIGABRT

This signal indicates an error detected by the program itself and reported by callingabort. See section.

intSIGIOT

Generated by the PDP-11 "iot" instruction. On most machines,this is just another name forSIGABRT.

intSIGTRAP

Generated by the machine's breakpoint instruction,and possibly other trap instructions. This signal is used by debuggers. Your program will probably only seeSIGTRAPif it is somehow executing bad instructions.

intSIGEMT

Emulator trap; this results from certain unimplemented instructions which might be emulated in software,or the operating system's failure to properly emulate them.

intSIGSYS

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.

.)

intSIGTERM

TheSIGTERMsignal is a generic signal used to cause program termination. UnlikeSIGKILL,this signal can be blocked,handled,and ignored. It is the normal way to politely ask a program to terminate.

The shell commandkillgeneratesSIGTERMby default.

intSIGINT

TheSIGINT("program interrupt") signal is sent when the user types the INTR character (normallyC-c). See section,for information about terminal driver support forC-c.

intSIGQUIT

TheSIGQUITsignal is similar toSIGINT,except that it's controlled by a different key--the QUIT character,usuallyC----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,for information about core dumps. See section,for information about terminal driver support.

Certain kinds of cleanups are best omitted in handlingSIGQUIT. For example,if the program creates temporary files,it should handle the other termination requests by deleting the temporary files. But it is better forSIGQUITnot to delete them,so that the user can examine them in conjunction with the core dump.

intSIGKILL

TheSIGKILLsignal 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 asC-corSIGTERM. If a process does not respond to any other termination signals,sending it aSIGKILLsignal will almost always cause it to go away.

In fact,ifSIGKILLfails to terminate a process,that by itself constitutes an operating system bug which you should report.

The system will generateSIGKILLfor a process itself under some unusual conditions where the program cannot possible continue to run (even to run a signal handler).

intSIGHUP

TheSIGHUP("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.

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.

,for information about functions that cause these signals to be sent.

intSIGALRM

This signal typically indicates expiration of a timer that measures real or clock time. It is used by thealarmfunction,for example.

intSIGVTALRM

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".

intSIGPROF

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.

fcntlto enable a particular file descriptior to generate these signals (see section). The default action for these signals is to ignore them.

intSIGIO

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 generateSIGIO; other kinds,including ordinary files,never generateSIGIOeven if you ask them to.

In the GNU systemSIGIOwill always be generated properly if you successfully set asynchronous mode withfcntl.

intSIGURG

This signal is sent when "urgent" or out-of-band data arrives on a socket. See section.

intSIGPOLL

This is a System V signal name,more or less similar toSIGIO. It is defined only for compatibility.

.

intSIGCHLD

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 viawaitorwaitpid(see section),whether your new handler applies to those processes or not depends on the particular operating system.

intSIGCLD

This is an obsolete name forSIGCHLD.

intSIGCONT

You can send aSIGCONTsignal 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,butSIGCONTalways makes the process continue regardless.

Most programs have no reason to handleSIGCONT; they simply resume execution without realizing they were ever stopped. You can use a handler forSIGCONTto 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.

intSIGSTOP

TheSIGSTOPsignal stops the process. It cannot be handled,ignored,or blocked.

intSIGTSTP

TheSIGTSTPsignal is an interactive stop signal. UnlikeSIGSTOP,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 handleSIGTSTPso they can turn echoing back on before stopping.

This signal is generated when the user types the SUSP character (normallyC-z). For more information about terminal driver support,see section.

intSIGTTIN

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 aSIGTTINsignal. The default action for this signal is to stop the process. For more information about how this interacts with the terminal driver,see section.

intSIGTTOU

This is similar toSIGTTIN,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.SIGTTOUis only generated for an attempt to write to the terminal if theTOSTOPoutput mode is set; see section.

SIGKILLsignals and (obviously)SIGCONTsignals. The signals are marked as pending,but not delivered until the process is continued. TheSIGKILLsignal always causes termination of the process and can't be blocked,handled or ignored. You can ignoreSIGCONT,but it always causes the process to be continued anyway if it is stopped. Sending aSIGCONTsignal to a process causes any pending stop signals for that process to be discarded. Likewise,any pendingSIGCONTsignals for a process are discarded when it receives a stop signal.

) receives aSIGTSTP,SIGTTIN,orSIGTTOUsignal 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 asSIGKILLorSIGHUP. In the GNU system,the process dies withSIGKILL; this avoids the problem of many stopped,orphaned processes lying around the system.

intSIGPIPE

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 aSIGPIPEsignal. IfSIGPIPEis blocked,handled or ignored,the offending call fails withEPIPEinstead.

Pipes and FIFO special files are discussed in more detail in section.

Another cause ofSIGPIPEis when you try to output to a socket that isn't connected. See section.

intSIGLOST

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,SIGLOSTis 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.

intSIGXCPU

CPU time limit exceeded. This signal is generated when the process exceeds its soft resource limit on CPU time. See section.

intSIGXFSZ

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.

intSIGUSR1

intSIGUSR2

TheSIGUSR1andSIGUSR2signals 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 ofSIGUSR1andSIGUSR2in section.

The default action is to terminate the process.

intSIGWINCH

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 handleSIGWINCH. When the signal arrives,it should fetch the new screen size and reformat its display accordingly.

intSIGINFO

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.

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.

strsignalandpsignal. 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) or it may come from a signal handler in the same process.

char *strsignal(intsignum)

This function returns a pointer to a statically-allocated string containing a message describing the signalsignum. 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.

This function is a GNU extension,declared in the header file`string.h'.

voidpsignal(intsignum,const char *message)

This function prints a message describing the signalsignumto the standard error output streamstderr; see section.

If you callpsignalwith amessagethat is either a null pointer or an empty string,psignaljust prints the message corresponding tosignum,adding a trailing newline.

If you supply a non-nullmessageargument,thenpsignalprefixes its output with this string. It adds a colon and a space character to separate themessagefrom the string corresponding tosignum.

This function is a BSD feature,declared in the header file`signal.h'.

sys_siglistwhich contains the messages for the various signal codes. This array exists on BSD systems,unlikestrsignal.

signalfunction. You can specify a built-in action (such as to ignore the signal),or you canestablish a handler.

sigactionfacility. This section describes both facilities and gives suggestions on which to use when.

signalfunction provides a simple interface for establishing an action for a particular signal. The function and associated macros are declared in the header file`signal.h'.

sighandler_t

This is the type of signal handler functions. Signal handlers take one integer argument specifying the signal number,and have return typevoid. So,you should define handler functions like this:

void handler (int signum) { ... }

The namesighandler_tfor this data type is a GNU extension.

sighandler_tsignal(intsignum,sighandler_taction)

Thesignalfunction establishesactionas the action for the signalsignum.

The first argument,signum,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---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,action,specifies the action to use for the signalsignum. This can be one of the following:

SIG_DFL

SIG_DFLspecifies the default action for the particular signal. The default actions for various kinds of signals are stated in section.

SIG_IGN

SIG_IGNspecifies 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 theSIGKILLorSIGSTOPsignals at all. You can ignore program error signals likeSIGSEGV,but ignoring the error won't enable the program to continue executing meaningfully. Ignoring user requests such asSIGINT,SIGQUIT,andSIGTSTPis 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.

handler

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.

If you set the action for a signal toSIG_IGN,or if you set it toSIG_DFLand 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.

Thesignalfunction returns the action that was previously in effect for the specifiedsignum. You can save this value and restore it later by callingsignalagain.

Ifsignalcan't honor the request,it returnsSIG_ERRinstead. The followingerrnoerror conditions are defined for this function:

EINVAL

You specified an invalidsignum; or you tried to ignore or provide a handler forSIGKILLorSIGSTOP.

#include 
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);

...

}

SIGQUITor 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.

sighandler_tssignal(intsignum,sighandler_taction)

Thessignalfunction does the same thing assignal; it is provided only for compatibility with SVID.

sighandler_tSIG_ERR

The value of this macro is used as the return value fromsignalto indicate an error.

sigactionfunction has the same basic effect assignal: to specify how a signal should be handled by the process. However,sigactionoffers more control,at the expense of more complexity. In particular,sigactionallows you to specify additional flags to control when the signal is generated and how the handler is invoked.

sigactionfunction is declared in`signal.h'.

struct sigaction

Structures of typestruct sigactionare used in thesigactionfunction to specify all the information about how to handle a particular signal. This structure contains at least the following members:

sighandler_t sa_handler

This is used in the same way as theactionargument to thesignalfunction. The value can beSIG_DFL,SIG_IGN,or a function pointer. See section.

sigset_t sa_mask

This specifies a set of signals to be blocked while the handler runs. Blocking is explained in section. Note that the signal that was delivered is automatically blocked by default before its handler is started; this is true regardless of the value insa_mask. If you want that signal not to be blocked within its handler,you must write code in the handler to unblock it.

int sa_flags

This specifies various flags which can affect the behavior of the signal. These are described in more detail in sectionsigaction.

intsigaction(intsignum,const struct sigaction *action,struct sigaction *old-action)

Theactionargument is used to set up a new action for the signalsignum,while theold-actionargument is used to return information about the action previously associated with this symbol. (In other words,old-actionhas the same purpose as thesignalfunction'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.)

Eitheractionorold-actioncan be a null pointer. Ifold-actionis a null pointer,this simply suppresses the return of information about the old action. Ifactionis a null pointer,the action associated with the signalsignumis unchanged; this allows you to inquire about how a signal is being handled without changing that handling.

The return value fromsigactionis zero if it succeeds,and-1on failure. The followingerrnoerror conditions are defined for this function:

EINVAL

Thesignumargument is not valid,or you are trying to trap or ignoreSIGKILLorSIGSTOP.

signalandsigaction

signalandsigactionfunctions within a single program,but you have to be careful because they can interact in slightly strange ways.

sigactionfunction specifies more information than thesignalfunction,so the return value fromsignalcannot express the full range ofsigactionpossibilities. Therefore,if you usesignalto save and later reestablish an action,it may not be able to reestablish properly a handler that was established withsigaction.

sigactionto save and restore a handler if your program usessigactionat all. Sincesigactionis more general,it can properly save and reestablish any action,regardless of whether it was established originally withsignalorsigaction.

signaland then examine it withsigaction,the handler address that you get may not be the same as what you specified withsignal. It may not even be suitable for use as an action argument withsignal. But you can rely on using it as an argument tosigaction. This problem never happens on the GNU system.

Portability Note:The basicsignalfunction is a feature of ANSI C,whilesigactionis part of the POSIX.1 standard. If you are concerned about portability to non-POSIX systems,then you should use thesignalfunction instead.

Function Example

,we gave an example of establishing a simple handler for termination signals usingsignal. Here is an equivalent example usingsigaction:

#include 
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,&old_action);

if (old_action.sa_handler != SIG_IGN)

sigaction (SIGHUP,NULL);

sigaction (SIGTERM,&old_action);

if (old_action.sa_handler != SIG_IGN)

sigaction (SIGTERM,NULL);

...

}

new_actionstructure with the desired parameters and passes it in thesigactioncall. The usage ofsigemptysetis described later; see section.

signal,we avoid handling signals previously set to be ignored. Here we can avoid altering the signal handler even momentarily,by using the feature ofsigactionthat lets us examine the current action without specifying a new one.

SIGINTwithout changing that action.

struct sigaction query_action;
if (sigaction (SIGINT,&query_action) < 0)

/ sigaction returns -1 in case of error. /

else if (query_action.sa_handler == SIG_DFL)

/ SIGINT is handled in the default,fatal manner. /

else if (query_action.sa_handler == SIG_IGN)

/ SIGINT is ignored. /

else

/ A programmer-defined signal handler is in effect. /

sigaction

sa_flagsmember of thesigactionstructure is a catch-all for special features. Most of the time,SA_RESTARTis a good value to use for this field.

sa_flagsis interpreted as a bit mask. Thus,you should choose the flags you want to set,OR those flags together,and store the result in thesa_flagsmember of yoursigactionstructure.

sigactionaffects one particular signal number,and the flags that you specify apply only to that particular signal.

signalsets all the flags to zero except forSA_RESTART,whose value depends on the settings you have made withsiginterrupt. See section,to see what this is about.

`signal.h'.

intSA_NOCLDSTOP

This flag is meaningful only for theSIGCHLDsignal. When the flag is set,the system delivers the signal for a terminated child process but not for one that is stopped. By default,SIGCHLDis delivered for both terminated children and stopped children.

Setting this flag for a signal other thanSIGCHLDhas no effect.

intSA_ONSTACK

If this flag is set for a particular signal number,the system uses the signal stack when delivering that kind of signal. See section. If a signal with this flag arrives and you have not set a signal stack,the system terminates the program withSIGILL.

intSA_RESTART

This flag controls what happens when a signal is delivered during certain primitives (such asopen,readorwrite),and the signal handler returns normally. There are two alternatives: the library function can resume,or it can return failure with error codeEINTR.

The choice is controlled by theSA_RESTARTflag 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.

),it inherits handling of signals from its parent process. However,when you load a new process image using theexecfunction (see section),any signals that you've defined your own handlers for revert to theirSIG_DFLhandling. (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.

SIG_DFLorSIG_IGN,as appropriate. It's a good idea to check to make sure that the shell has not set up an initial action ofSIG_IGNbefore you establish your own signal handlers.

SIGHUP,but not ifSIGHUPis currently ignored:

...
struct sigaction temp;
sigaction (SIGHUP,&temp);
if (temp.sa_handler != SIG_IGN)

{

temp.sa_handler = handle_sighup;

sigemptyset (&temp.sa_mask);

sigaction (SIGHUP,&temp,NULL);

}

signalorsigactionfunctions.

signalorsigactionto tell the operating system to call it when a signal arrives. This is known asestablishingthe handler. See section.

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.

SIGALRMand the I/O and interprocess communication signals. But a handler forSIGINTmight also return normally after setting a flag that tells the program to exit at a convenient time.

.

sig_atomic_tfor reasons described in section.

SIGALRMsignal has arrived. This technique is useful because it allows the iteration in progress when the signal arrives to complete before the loop exits.

#include 
#include 
#include 
/ 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;

}

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

exit or abort,but reraising the signal

sets the return status from the process correctly. /

raise (sig);

}

setjmpandlongjmpfacilities (see section).

.

#include 
#include 
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 {

...

}

}

sigprocmask,if you want to allow more signals of this type to arrive; see section.)

sa_maskmember of the action structure passed tosigactionto 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.

sigprocmaskinside the handler only affects what signals can arrive during the execution of the handler itself,not what signals can arrive once the handler returns.

Portability Note:Always usesigactionto 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 withsignalautomatically sets the signal's action back toSIG_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.

SIGCHLDthat 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 waitpid.  */
  int status;
};
struct process *process_list;

/* Nonzero means some child's status has changed
   so look at process_list for the details.  */
int process_status_change;

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 &amp;&amp; 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 <code>status</code> 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,&amp;input_wait_mask);

    /* The program should check this flag from time to time
       to see if there is any news in <code>process_list</code>.  */
    ++process_status_change;
  }

/* Loop around to handle all the processes
   that have something to tell us.  */
}

}

process_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 p->status ...
    }
}

p->statusuntil it sees that status has been validly stored. This is to make sure that the status cannot change in the middle of accessing it. Oncep->have_statusis 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,for more information about coping with interruptions during accessings of a variable.

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 p->status ...

}

}

}

intvariable into another can take two instructions on most machines.

If your handler needs to access any global variables from your program,declare those variablesvolatile. This tells the compiler that the value of the variable might change asynchronously,and inhibits certain optimizations that would be invalidated by such modifications.
• If you call a function in the handler,make sure it isreentrantwith respect to signals,or else make sure that the signal cannot interrupt a call to a related function.

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 usesgethostbyname. This function returns its value in a static object,reusing the same object each time. If the signal happens to arrive during a call togethostbyname,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 usegethostbynameor 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 withfprintf. Suppose that the program was in the middle of anfprintfcall 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,mallocandfreeare 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) are certainly not safe to use in a signal handler.
• Any function that modifieserrnois non-reentrant,but you can correct for this: in the handler,save the original value oferrnoand 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.
• 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.

atomic. 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.

).

#include 
#include 
struct two_words { int a,b; } memory;
void

handler(int signum)

{

printf ("%d,%dn",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;

}

}

memorywith zeros,ones,zeros,alternating forever; meanwhile,once per second,the alarm signal handler prints the current contents. (Callingprintfin the handler is safe in this program because it is certainly not being called outside the handler when the signal happens.)

memory,and the value is stored one word at a time. If the signal is delivered in between these instructions,the handler might find thatmemory.ais zero andmemory.bis one (or vice versa).

memorywith just one instruction that cannot be interrupted. On these machines,the handler will always print two zeros or two ones.

sig_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.

sig_atomic_tis always an integer data type,but which one it is,and how many bits it contains,may vary from machine to machine.

sig_atomic_t

This is an integer data type. Objects of this type are always accessed atomically.

intand other integer types no longer thanintare 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.

openorreadis waiting for an I/O device. If the signal handler returns,the system faces the question: what should happen next?

EINTR. This is flexible,but usually inconvenient. Typically,POSIX applications that use signal handlers must check forEINTRafter 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.

TEMP_FAILURE_RETRY:

TEMP_FAILURE_RETRY(expression)

This macro evaluatesexpressiononce. If it fails and reports error codeEINTR,TEMP_FAILURE_RETRYevaluates it again,and over and over until the result is not a temporary failure.

The value returned byTEMP_FAILURE_RETRYis whatever valueexpressionproduced.

EINTRentirely 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 withEINTR.

sigactionto establish a signal handler,you can specify how that handler should behave. If you specify theSA_RESTARTflag,return from that handler will resume a primitive; otherwise,return from that handler will causeEINTR. See sectionsigaction.

siginterruptfunction. See section.

sigactionorsiginterruptwhat 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_BSD_SOURCEor_GNU_SOURCEbefore callingsignal,the default is to resume primitives; otherwise,the default is to make them fail withEINTR. (The library contains alternate versions of thesignalfunction,and the feature test macros determine which one you really call.) See section.

EINTRamong the error codes it can return.

readorwriteis 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.

),where splitting onereadorwriteinto 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.

raisefunction. This function is declared in`signal.h'.

intraise(intsignum)

Theraisefunction sends the signalsignumto 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 ofsignumis invalid.

intgsignal(intsignum)

Thegsignalfunction does the same thing asraise; it is provided only for compatibility with SVID.

raiseis to reproduce the default behavior of a signal that you have trapped. For instance,suppose a user of your program types the SUSP character (usuallyC-z; see section) to send it an interactive stop stop signal (SIGTSTP),and you want to clean up some internal data buffers before stopping. You might set this up like this:

#include 
/ 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,tstp_handler);

...

}

Portability note:raisewas invented by the ANSI C committee. Older systems may not support it,so usingkillmay be more portable. See section.

killfunction 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.

.

killfunction is declared in`signal.h'.

intkill(pid_tpid,intsignum)

Thekillfunction sends the signalsignumto the process or process group specified bypid. Besides the signals listed in section,signumcan also have a value of zero to check the validity of thepid.

Thepidspecifies the process or process group to receive the signal:

pid> 0

The process whose identifier ispid.

pid== 0

All processes in the same process group as the sender.

pid< -1

The process group whose identifier is -pid.

pid== -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 signalsignumto itself with a call likekill (getpid(),signum). Ifkillis used by a process to send a signal to itself,and the signal is not blocked,thenkilldelivers at least one signal (which might be some other pending unblocked signal instead of the signalsignum) to that process before it returns.

The return value fromkillis zero if the signal can be sent successfully. Otherwise,no signal is sent,and a value of-1is returned. Ifpidspecifies sending a signal to several processes,killsucceeds 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 followingerrnoerror conditions are defined for this function:

EINVAL

Thesignumargument is an invalid or unsupported number.

EPERM

You do not have the privilege to send a signal to the process or any of the processes in the process group named bypid.

ESCRH

Thepidargument does not refer to an existing process or group.

intkillpg(intpgid,intsignum)

This is similar tokill,but sends signalsignumto the process grouppgid. This function is provided for compatibility with BSD; usingkillto do this is more portable.

kill,the callkill (getpid (),sig)has the same effect asraise (sig).

kill

killto 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,killis 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 execption 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. Thesuprogram does this.

.

`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.

SIGCONTsignal is a special case. It can be sent if the sender is part of the same session as the receiver,regardless of user IDs.

killfor Communication

SIGUSR1andSIGUSR2signals are provided for. Since these signals are fatal by default,the process that is supposed to receive them must trap them throughsignalorsigaction.

SIGUSR1signal,using thekillfunction.

#include 
#include 
#include 
#include 
/ When a SIGUSR1 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;

}

.

SIG_IGN. But it is useful to block signals briefly,to prevent them from interrupting sensitive operations. For instance:

You can use thesigprocmaskfunction to block signals while you modify global variables that are also modified by the handlers for these signals.
• You can setsa_maskin yoursigactioncall to block certain signals while a particular signal handler runs. This way,the signal handler can run without being interrupted itself by signals.

sigprocmaskgives 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.

sig_atomic_t(see section),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.

sig_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.

signal setto 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.

`signal.h'.

sigset_t

Thesigset_tdata 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 fromsigset_tobjects--don't try to manipulate them directly.

sigemptysetand then add specified signals individually. Or you can specify it to be full withsigfillsetand then delete specified signals individually.

sigset_tobject 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.)

intsigemptyset(sigset_t *set)

This function initializes the signal setsetto exclude all of the defined signals. It always returns0.

intsigfillset(sigset_t *set)

This function initializes the signal setsetto include all of the defined signals. Again,the return value is0.

intsigaddset(sigset_t *set,intsignum)

This function adds the signalsignumto the signal setset. Allsigaddsetdoes is modifyset; it does not block or unblock any signals.

The return value is0on success and-1on failure. The followingerrnoerror condition is defined for this function:

EINVAL

Thesignumargument doesn't specify a valid signal.

intsigdelset(sigset_t *set,intsignum)

This function removes the signalsignumfrom the signal setset. Allsigdelsetdoes is modifyset; it does not block or unblock any signals. The return value and error conditions are the same as forsigaddset.

intsigismember(const sigset_t *set,intsignum)

Thesigismemberfunction tests whether the signalsignumis a member of the signal setset. It returns1if the signal is in the set,0if not,and-1if there is an error.

The followingerrnoerror condition is defined for this function:

EINVAL

Thesignumargument doesn't specify a valid signal.

signal mask. Each process has its own signal mask. When you create a new process (see section),it inherits its parent's mask. You can block or unblock signals with total flexibility by modifying the signal mask.

sigprocmaskfunction is in`signal.h'.

intsigprocmask(inthow,const sigset_t *set,sigset_t *oldset)

Thesigprocmaskfunction is used to examine or change the calling process's signal mask. Thehowargument determines how the signal mask is changed,and must be one of the following values:

SIG_BLOCK

Block the signals inset---add them to the existing mask. In other words,the new mask is the union of the existing mask andset.

SIG_UNBLOCK

Unblock the signals inset---remove them from the existing mask.

SIG_SETMASK

Usesetfor the mask; ignore the previous value of the mask.

The last argument,oldset,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 theoldsetargument. Similarly,if you want to know what's in the mask without changing it,pass a null pointer forset(in this case thehowargument is not significant). Theoldsetargument is often used to remember the previous signal mask in order to restore it later. (Since the signal mask is inherited overforkandexeccalls,you can't predict what its contents are when your program starts running.)

If invokingsigprocmaskcauses any pending signals to be unblocked,at least one of those signals is delivered to the process beforesigprocmaskreturns. The order in which pending signals are delivered is not specified,but you can control the order explicitly by making multiplesigprocmaskcalls to unblock various signals one at a time.

Thesigprocmaskfunction returns0if successful,and-1to indicate an error. The followingerrnoerror conditions are defined for this function:

EINVAL

Thehowargument is invalid.

You can't block theSIGKILLandSIGSTOPsignals,but if the signal set includes these,sigprocmaskjust ignores them instead of returning an error status.

Remember,too,that blocking program error signals such asSIGFPEleads to undesirable results for signals generated by an actual program error (as opposed to signals sent withraiseorkill). 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.

SIGALRMsignals 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 additionalSIGALRMsignals from arriving in the meantime by wrapping the critical part of the code with calls tosigprocmask,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)

{

actions-if-not-arrived

flag = 0;

}

sigprocmask (SIG_UNBLOCK,NULL);
  ...
}
}

SIGTSTP,for instance,then the arrival of that signal forces furtherSIGTSTPsignals to wait during the execution of the handler.

sa_maskmember of thesigactionstructure.

#include 
#include 
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);

}

sigprocmaskwithin your handler to block or unblock signals as you wish.

sigpending. This function is declared in`signal.h'.

intsigpending(sigset_t *set)

Thesigpendingfunction stores information about pending signals inset. 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 usingsigismember; see section.)

The return value is0if successful,and-1on failure.

#include 
#include 
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. /

}

SIGINTsignal is pending when anotherSIGINTsignal arrives,your program will probably only see one of them when you unblock this signal.

Portability Note:Thesigpendingfunction is new in POSIX.1. Older systems have no equivalent facility.

/* 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 mumble,without worrying about interruption. /

mumble.a = 1;

mumble.b = hack ();

mumble.c = frob;

/ We have updated mumble.  Handle any signal that came in. /

defer_signal--;

if (defer_signal == 0 && signal_pending != 0)

raise (signal_pending);

}

signal_pending. That way,we can handle several types of inconvenient signals with the same mechanism.

defer_signalso that nested critical sections will work properly; thus,ifupdate_mumblewere called withsignal_pendingalready nonzero,signals would be deferred not only withinupdate_mumble,but also within the caller. This is also why we do not checksignal_pendingifdefer_signalis still nonzero.

defer_signalrequire 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.

defer_signalbefore testingsignal_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--;

ifstatement and the decrement would be effetively "lost" for an indefinite amount of time. The handler would merely setdefer_signal,but the program having already tested this variable,it would not test the variable again.

timing 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.

defer_signalas a counter which must be tested along withsignal_pending. After all,testing for zero is cleaner than testing for one. But if you did not usedefer_signalas 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 fordefer_signal: it will reduce the chance you will write the code in the wrong order and create a subtle bug.)

pause

pause. Please read about its disadvantages,in the following section,before you use it.

intpause()

Thepausefunction 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,thenpausereturns. This is considered an unsuccessful return (since "successful" behavior would be to suspend the program forever),so the return value is-1. Even if you specify that other primitives should resume when a system handler returns (see section),this has no effect onpause; it always fails when a signal is handled.

The followingerrnoerror conditions are defined for this function:

EINTR

The function was interrupted by delivery of a signal.

If the signal causes program termination,pausedoesn't return (obviously).

Thepausefunction is declared in`unistd.h'.

pause

pausecan conceal serious timing errors that can make a program hang mysteriously.

pauseif the real work of your program is done by the signal handlers themselves,and the "main program" does nothing but callpause. 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 callpauseagain.

pauseto 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 usepausereliably. Here is an example of this problem:

/* usr_interrupt is set by the signal handler.  */
if (!usr_interrupt)
  pause ();
/ Do work once the signal arrives.  /

...

usr_interruptis checked,but before the call topause. If no further signals arrive,the process would never wake up again.

sleepin a loop,instead of usingpause. (See section,for more aboutsleep.) Here is what this looks like:

/* usr_interrupt is set by the signal handler.
while (!usr_interrupt)
  sleep (1);
/ Do work once the signal arrives.  /

...

sigsuspend.

sigsuspend

sigsuspend. By usingsigsuspendin a loop,you can wait for certain kinds of signals,while letting other kinds of signals be handled by their handlers.

intsigsuspend(const sigset_t *set)

This function replaces the process's signal mask withsetand 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 ofsetarrives.

If the process is woken up by deliver of a signal that invokes a handler function,and the handler function returns,thensigsuspendalso returns.

The mask remainssetonly as long assigsuspendis waiting. The functionsigsuspendalways restores the previous signal mask when it returns.

The return value and error conditions are the same as forpause.

sigsuspend,you can replace thepauseorsleeploop 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,NULL);

sigsuspendreturns,it resets the process's signal mask to the original value,the value from before the call tosigsuspend---in this case,theSIGUSR1signal is once again blocked. The second call tosigprocmaskis necessary to explicitly unblock this signal.

whileloop is necessary at all,since the program is apparently only waiting for oneSIGUSR1signal. The answer is that the mask passed tosigsuspendpermits 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 setusr_interrupt,it just suspends itself again until the "right" kind of signal eventually arrives.

SIGSTKSZis defined to a canonical size for signal stacks. You can usemallocto allocate the space for the stack. Then callsigaltstackorsigstackto tell the system to use that space for the signal stack.

sigstackis the older interface,which comes from 4.2 BSD.sigaltstackis the newer interface,and comes from 4.4 BSD. Thesigaltstackinterface 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.

struct sigaltstack

This structure describes a signal stack. It contains the following members:

void *ss_sp

This points to the base of the signal stack.

size_t ss_size

This is the size (in bytes) of the signal stack which`ss_sp'points to. You should set this to however much space you allocated for the stack. There are two macros defined in`signal.h'that you should use in calculating this size:

SIGSTKSZ

This is the canonical size for a signal stack. It is judged to be sufficient for normal uses.

MINSIGSTKSZ

This is the amount of signal stack space the operating system needs just to implement signal delivery. The size of a signal stackmustbe greater than this. For most cases,just usingSIGSTKSZforss_sizeis 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 allocateMINSIGSTKSZadditional bytes for the signal stack and increasess_sizeaccordinly.

int ss_flags

This field contains the bitwise OR of these flags:

SA_DISABLE

This tells the system that it should not use the signal stack.

SA_ONSTACK

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.

intsigaltstack(const struct sigaltstack *stack,struct sigaltstack *oldstack)

Thesigaltstackfunction 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.

Ifoldstackis not a null pointer,information about the currently installed signal stack is returned in the location it points to. Ifstackis not a null pointer,then this is installed as the new stack for use by signal handlers.

The return value is0on success and-1on failure. Ifsigaltstackfails,it setserrnoto one of these values:

EINVAL

You tried to disable a stack that was in fact currently in use.

ENOMEM

The size of the alternate stack was too small. It must be greater thanMINSIGSTKSZ.

sigstackinterface. You should usesigaltstackinstead on systems that have it.

struct sigstack

This structure describes a signal stack. It contains the following members:

void *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.

int ss_onstack

This field is true if the process is currently using this stack.

intsigstack(const struct sigstack *stack,struct sigstack *oldstack)

Thesigstackfunction 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,then this is installed as the new stack for use by signal handlers.

The return value is0on success and-1on failure.

BSD Unix represents signal masks as anintbit mask,rather than as asigset_tobject.
• 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.

`signal.h'.

struct sigvec

This data type is the BSD equivalent ofstruct sigaction(see section); it is used to specify signal actions to thesigvecfunction. It contains the following members:

sighandler_t sv_handler

This is the handler function.

int sv_mask

This is the mask of additional signals to be blocked while the handler function is being called.

int 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 assv_onstack.

sv_flagsfield of asigvecstructure. This field is a bit mask value,so you bitwise-OR the flags of interest to you together.

intSV_ONSTACK

If this bit is set in thesv_flagsfield of asigvecstructure,it means to use the signal stack when delivering the signal.

intSV_INTERRUPT

If this bit is set in thesv_flagsfield of asigvecstructure,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 aEINTRerror status. See section.

intSV_RESETHAND

If this bit is set in thesv_flagsfield of asigvecstructure,it means to reset the action for the signal back toSIG_DFLwhen the signal is received.

intsigvec(intsignum,const struct sigvec *action,struct sigvec *old-action)

This function is the equivalent ofsigaction(see section); it installs the actionactionfor the signalsignum,returning information about the previous action in effect for that signal inold-action.

intsiginterrupt(intsignum,intfailflag)

This function specifies which approach to use when certain primitives are interrupted by handling signalsignum. Iffailflagis false,signalsignumrestarts primitives. Iffailflagis true,handlingsignumcauses these primitives to fail with error codeEINTR. See section.

intsigmask(intsignum)

This macro returns a signal mask that has the bit for signalsignumset. You can bitwise-OR the results of several calls tosigmasktogether 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.

intsigblock(intmask)

This function is equivalent tosigprocmask(see section) with ahowargument ofSIG_BLOCK: it adds the signals specified bymaskto the calling process's set of blocked signals. The return value is the previous set of blocked signals.

intsigsetmask(intmask)

This function equivalent tosigprocmask(see section) with ahowargument ofSIG_SETMASK: it sets the calling process's signal mask tomask. The return value is the previous set of blocked signals.

intsigpause(intmask)

This function is the equivalent ofsigsuspend(see section): it sets the calling process's signal mask tomask,and waits for a signal to arrive. On return the previous set of blocked signals is restored.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!