Signal (Sigpipe, sig_ign) effect

Signal (Sigpipe, sig_ign)

When the server is close to a connection, the client then sends the data.

According to the provisions of the TCP protocol, you will receive a RST response, when the client sends data to this server, the system sends out a SIGPIPE signal to the process, telling the process that the connection has been disconnected and no more writing.

According to the default processing rules of the signal sigpipe the default execution action of the signal is terminate (terminating, exiting), so the client exits.

If you do not want the client to exit you can set Sigpipe to Sig_ign

such as: signal (sigpipe,sig_ign);

At this time sigpipe to the system processing.

The server uses the fork, to collect the garbage process, to prevent the production of zombie processes, you can handle:

Signal (sigchld,sig_ign); To the system init to recycle.

The subprocess will not spawn a zombie process here.

============

wrote a server program, tested under Linux , and then wrote in C + + a client with a tens number of short links for stress testing. But the server is always inexplicable exit, no core file.

The final question is determined to call two write for a socket that has been closed, and the second will generate a sigpipe signal that ends the process by default.

The specific analysis can be combined with TCP's "four-time handshake" shutdown. TCP is a full-duplex channel, can be regarded as two single-channel, TCP connection at each end of the two endpoints are responsible for one.

When Close is called on the peer, although the intention is to close the entire two channels, but this side just received fin packets.

According to the semantics of the TCP protocol, the peer only shuts down the single channel it is responsible for, and continues to receive data.

That is, because of the limitations of the TCP protocol, an endpoint cannot know whether the socket on the peer is called close or shutdown.

Call the Read method on a socket that has received a FIN packet, and if the receive buffer is empty, return 0, which is often said to indicate that the connection is closed.

But when the write method is called for the first time, it returns the correct write (send) if the send buffer is not a problem.

But the message sent will cause the RST message to be sent to the end, because the socket on the end has called close, closed completely, neither sent nor received data.

Therefore, the second call to the Write method (assuming that the RST is received) generates a sigpipe signal that causes the process to exit.

To avoid a process exit, you can either capture the sigpipe signal or ignore it and set the sig_ign signal handler function for it:

Signal (sigpipe, sig_ign);

This way, when the write method is called for the second time, 1 is returned, and errno is set to sigpipe. The program will know that the peer is closed.

When writing a socket program under Linux , if you try to send to a disconnected socket, you will let the underlying throw a sigpipe signal.

The default approach to this signal is to exit the process, which is not what we expect most of the time. Therefore, we need to overload this signal processing method.

You can safely mask sigpipeby calling the following code:

Signal (Sigpipe, sig_ign);

My program generates this signal because the client side through the pipe to send information to the server side, then shut down the client side, the server side, return information to the client side when the broken pipe signal is generated, the server will be the system ended.

For generating signals, we can use the method signal(int signum, sighandler_t handler) to set the signal processing before generating the signal.

If you do not call this method, the default processing method is called: Abort the program and display the prompt message (which is the problem we often encounter).

We can call the processing method of the system, or we can customize the processing method.
Three processing methods are defined inside the system:

(1) SIG_DFL signal-specific default action:

(a) If the default action is to suspend a thread, execution of that thread is temporarily suspended.

When a thread pauses, any additional signals sent to the thread are not delivered until the thread begins execution, except Sigkill.

(b) The signal action of the suspend signal is set to SIG_DFL, and its default action is to ignore the signal (SIGCHLD).

(2) sig_ign ignore signal

(a) The delivery of the signal has no effect on the thread

(b) The system does not allow the action of the Sigkill or sigtop signal to be set to SIG_DFL 3) Sig_err

I called signal(sigpipe, sig_ign) in the project so that when the Sigpipe signal was generated, it would not abort the program and ignore the signal directly.

http://blog.163.com/[email protected]/blog/static/170596595201221942952676/

Signal (Sigpipe, sig_ign) effect