我写了服务器程序，在Linux上测试，然后在c上写了客户端在千万级别数的短链路上进行压力测试。 但是服务器总是莫名其妙地退出，没有酷睿文件。
最后一个问题是，如果对一个对方关闭的套接字调用write两次，则第二次生成SIGPIPE信号，默认情况下该进程将终止。
具体分析可以结合TCP的“4次握手”关闭。 TCP是全双工信道，可以视为两个专用信道，TCP连接两端的两个端点各负责一个。 当另一方调用close时，意图关闭整个两个信道，但本地方只接收FIN分组。 根据TCP协议的含义，相反侧表示只关闭负责的一个单独通道。 可以继续接收数据。 这意味着，由于TCP协议的限制，端点无法知道对方的套接字是否调用了关闭或关闭。
对接收FIN包的套接字调用read方法，如果接收缓冲区为空，则返回0。 这表示常用的连接已关闭。 但是，第一次调用write方法时，如果发送缓冲区没有问题，则返回正确的写入(发送)。 但是，由于发送的消息导致对方的套接字已经调用了close，所以RST消息既不会被完全关闭，也不会被发送或接收。 因此，第二次调用write方法时，将在收到RST后生成SIGPIPE信号，并终止该进程。
要防止进程终止，请捕获SIGPIPE信号，或忽略并设置3358www.Sina.com/信号处理程序：
3358 www.Sina.com/(http://www.Sina.com /，http://www.Sina.com/)；
这将在第二次调用write方法时返回-1，如果errno设置为SIG_IGN.程序，则表明对方已关闭。
在signal上编写套接字程序时，如果尝试向离散套接字发送send，则会向基础上发出SIGPIPE信号。
这个信号的默认处理方法是终止该过程，在很多情况下这不是我们所期望的。 因此，需要重新加载该信号的处理方法。 调用以下代码时，将显示SIG_IGN
signal(SIGpipe，SIG_IGN )；
我的程序发出这个信号的原因是：
客户端用pipe向服务器发送消息后，关闭客户端。 此时，服务器端将在向客户端返回消息时生成Broken pipe信号，服务器将在系统中退出。
要生成信号，请在生成信号之前使用方法http://www.Sina.com/(intsignum，sighandler_t handler )设置信号处理。 如果未调用此方法，系统将调用缺省处理方法。 中止程序，显示提示消息。 这是我们经常遇到的问题。 我们可以调用系统的处理方法，也可以定制处理方法。
系统定义了三种处理方法。SIGPIPE
(a )如果默认操作是线程暂停，则该线程的执行将暂停。 线程中断时，发送到线程的其他信号在线程开始执行之前不会传递，SIGKILL除外。
(b )将挂起信号的信号操作设置为SIG_DFL，并且默认操作是信号忽略(SIGCHLD )。linux
(a )此信号的传递不影响线程
(b )系统不允许将SIGKILL或SIGTOP信号的操作设置为SIG_DFL
3 ) SIG_ERR
项目调用http://www.Sina.com/(http://www.Sina.com/，http://www.Sina.com/)，使http://www.Sina.com /信号