10.3 Signal function

The simplest interface to the signal characteristics of a UNIX system is the signal function:

  
 

   
  

  
#include <signal.h>
   
  

  
void (*signal(int signo, void(* func)(int)))(int);
   
  

  
    returns  :  previous disposition of signal   ( see following  Span class= "pun") if   OK   sig_err On Error    
  
 

The function signal is defined by ISO C and does not involve multi-process, process group Terminal IO, etc., so the definition of its signal is ambiguous and therefore almost useless for UNIX systems.

The implementation that inherits from Unix System v supports the signal function, but provides an older version of the unreliable signal semantics (which we'll describe in section 10.4), and the function signal provides backward-compatible features, These unreliable signals should no longer be used by newly developed applications.

The 4.4BSD also provides the signal function, but it is defined according to the sigaction function (we will talk about it in 10.14), so the function is used on 4.4BSD signal Provides new and reliable signal semantics. Many operating systems today use this approach, but Solaris 10 is also a signal function that inherits System V semantics.

Since the semantics of the signal function in different implementations are inconsistent, we must replace it with the function sigaction , and all the examples used in this book are the signal functions given in 10.18. This ensures consistency on different platforms.

The parameter Signo parameter is the name of the signal listed in Figure 10.1, and the parameter Func value can be one of the following three types:
A. Constant sig_ign; indicates that the system ignores the signal and that we cannot ignore two signals:SIGKILL,SIGSTOP.
B. Constant SIG_DFL; Indicates the default action that tells the system to perform the signal, see the last column in Figure 10.1.
C. The function address that is called when the signal appears, indicating that we are capturing the signal, and then calling the signal handler function or the signal-catching function.

The prototype of the function signal indicates that the function has two parameters and returns a function pointer that corresponds to the function's return value (void). The first parameter of the function signal is Signo, which is a shaping, The second argument is a function pointer, which corresponds to a function pointer with a shape parameter, the return value is void, and the function pointer returned by signal functions with an shaping parameter. When we call the function signal to establish the signal processing function, the second parameter is the parameter pointing to the function pointer, the return value is the original signal handler function pointer.

The more complex signal function prototypes described above can be defined using typedef simplification as follows:

 
   
  

  
    
   
typedef void Sigfunc(int);
  
    
   
Sigfunc *signal(int, Sigfunc *);
 
   
  

If you look at your system header file <signal.h> , we most likely see the following format definition:

 
   
  

  
    
   
#define SIG_ERR (void (*)())-1
  
    
   
#define SIG_DFL (void (*)())0
  
    
   
#define SIG_IGN (void (*)())1
 
   
  

These constants can be used to replace function pointers, such as the second parameter in signal , or the return value of a signal function. These three values must not necessarily be -1,0,1, but must be non-declarative function addresses. So many Unix systems use the above values.

Figure 10.2 shows the program below, which captures the user-defined signal and prints out the signal number. The function Pause We will describe in 10.10, which instructs the process to simply suspend the call to the function until a signal arrives.

  
 

   
  

  
#include "apue.h"
   
  

  

   
  

  
void sig_usr(int signo)
   
  

  
{
   
  

  
 if(signo == SIGUSR1)
   
  

  
 printf("received SIGUSR1\n");
   
  

  
 else if(signo == SIGUSR2)
   
  

  
 printf("received SIGUSR2\n");
   
  

  
 else
   
  

  
 err_dump("received signal %d\n", signo);
   
  

  
}
   
  

  

   
  

  
int main(void)
   
  

  
{
   
  

  
 if(signal(SIGUSR1, sig_usr) == SIG_ERR)
   
  

  
 {
   
  

  
 err_sys("can‘t catch SIGUSR1");
   
  

  
 }
   
  

  
 if(signal(SIGUSR2, sig_usr) == SIG_ERR)
   
  

  
 {
   
  

  
 err_sys("can‘t catch SIGUSR2");
   
  

  
 }
   
  

  
 while(1) pause();
   
  

  
}
  
 

We run the program in the background and use the command Kill (1) to send a signal, note that kill in the UNIX system is a misnomer, command kill(1) and function kill(2) is simply sending a signal to a process or process group, whether the signal terminates the process depends on what signal is sent and whether the process captures the signal.

  
 

   
  

  
[email protected]:~/UnixProgram/Chapter10$ ./10_2.exe & 在后台启动应用
   
  

  
[2] 1907 作业控制shell打印作业号以及进程号
   
  

  
[email protected]:~/UnixProgram/Chapter10$ kill -USR1 1907 发送信号SIGUSR1
   
  

  
received SIGUSR1
   
  

  
[email protected]:~/UnixProgram/Chapter10$ kill -USR2 1907 发送信号SIGUSR2
   
  

  
received SIGUSR2
   
  

  
[email protected]:~/UnixProgram/Chapter10$ kill 1907 发送信号SIGTERM
   
  

  
[email protected]:~/UnixProgram/Chapter10$ 
   
  

  
[2]+ Terminated ./10_2.exe
  
 

When we send the SIGTERM signal, the process is terminated because it does not process the signal, and the default processing of the signal is to terminate the process.

Program start-up

When a program is executed, the state of all signals is either default or ignored, and normally all signals are set to their default behavior, unless the process calling the EXEC function is ignoring the signals. In particular, the EXEC function modifies the behavior of all signals captured prior to exec to their default behavior, and does not handle other signals. (Normally, after a process that captures a signal executes the EXEC function, it cannot be caught in the same function in a new program because the address of the signal capture function is likely to have no meaning in the new program.) )

A special example of the above signal state processing is the interactive Shell's handling of the terminal of the background process and the processing of the stop signal, for shells that do not support job control, such as when we execute a program in the background, say:

 
   
  

  
    
   
cc main.c &
 
   
  

The shell will automatically set the interrupt and stop signal of the background process to ignore, after which, even if we type the break character on the keyboard does not affect the background process, if we do not, we enter the interrupt character, not only the foreground process will terminate the run, all the background process will also be terminated.

Many interactive processes are captured by code similar to the following to capture both of these signals:

  
 

   
  

  
void sig_int(int),sig_quit(int);
   
  

  
if(signal(SIGINT, SIG_IGN) != SIG_IGN)
   
  

  
 signal(SIGINT, sig_int);
   
  

  
if(signal(SIGQUIT, SIG_IGN) != SIG_IGN)
   
  

  
 signal(SIGQUIT, sig_quit);
  
 

Using this method, the process is captured only if the signal is not ignored.

These two calls to the signal function also show a limitation of the signal function: We cannot obtain the current disposition of the signal without modifying the disposition of the signal. In a later chapter, we will see how we can use the function sigaction to get its current disposition without any modification to the signal disposition.

Process Creation

When a process calls a function fork , the child process inherits the signal processing method of all the parent processes, where the address of the signal capture function still makes sense in the child process because the child process starts running from the memory image of the parent process.

From for notes (Wiz)

10.3 Signal function