signal(SIGCHLD, SIG_IGN)和signal(SIGPIPE, SIG_IGN);

 signal(SIGCHLD, SIG_IGN)和signal(SIGPIPE, SIG_IGN);
signal(SIGCHLD, SIG_IGN);

因为并发服务器常常fork很多子进程,子进程终结之后需要服务器进程去wait清理资源。如果将此信号的处理方式设为忽略,可让内核把僵尸子进程转交给init进程去处理,省去了大量僵尸进程占用系统资源。(Linux Only)

对于某些进程,特别是服务器进程往往在请求到来时生成子进程处理请求。如果父进程不等待子进程结束,子进程将成为僵尸进程(zombie)从而占用系统资源。如果父进程等待子进程结束,将增加父进程的负担,影响服务器进程的并发性能。在Linux下可以简单地将 SIGCHLD信号的操作设为SIG_IGN。

signal(SIGPIPE, SIG_IGN);

TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条. 当对端调用close时, 虽然本意是关闭整个两条信道,
但本端只是收到FIN包. 按照TCP协议的语义, 表示对端只是关闭了其所负责的那一条单工信道, 仍然可以继续接收数据. 也就是说, 因为TCP协议的限制,
一个端点无法获知对端的socket是调用了close还是shutdown.

对一个已经收到FIN包的socket调用read方法,
如果接收缓冲已空, 则返回0, 这就是常说的表示连接关闭. 但第一次对其调用write方法时, 如果发送缓冲没问题, 会返回正确写入(发送).
但发送的报文会导致对端发送RST报文, 因为对端的socket已经调用了close, 完全关闭, 既不发送, 也不接收数据. 所以,
第二次调用write方法(假设在收到RST之后), 会生成SIGPIPE信号, 导致进程退出.

为了避免进程退出, 可以捕获SIGPIPE信号, 或者忽略它, 给它设置SIG_IGN信号处理函数:

signal(SIGPIPE, SIG_IGN);

这样, 第二次调用write方法时, 会返回-1, 同时errno置为SIGPIPE. 程序便能知道对端已经关闭.
http://blog.csdn.net/xinguan1267/article/details/17357093
时间: 2024-10-10 07:43:33

signal(SIGCHLD, SIG_IGN)和signal(SIGPIPE, SIG_IGN);的相关文章

signal(SIGPIPE, SIG_IGN)作用

signal(SIGPIPE, SIG_IGN) 当服务器close一个连接时,若client端接着发数据. 根据TCP 协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. 根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止.退出),所以client会退出. 若不想客户端退出可以把SIGPIPE设为SIG_IGN 如:    signal(SIGPIPE,SIG_I

signal(SIGPIPE, SIG_IGN)

转自http://blog.163.com/[email protected]/blog/static/170596595201221942952676/ 当服务器close一个连接时,若client端接着发数据.根据TCP 协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. 根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止.退出),所以client会退出.若不想

signal(SIGPIPE, SIG_IGN) (转)

signal(SIGPIPE, SIG_IGN) (转) signal(SIGPIPE, SIG_IGN) 当服务器close一个连接时,若client端接着发数据. 根据TCP 协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. 根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止.退出),所以client会退出. 若不想客户端退出可以把SIGPIPE设为SIG_I

signal(SIGCHLD, SIG_IGN);的使用及验证

#include <stdio.h> #include <unistd.h> #include <sys/types.h> #include<stdlib.h> #include<signal.h> int main(int argc , char **argv) {signal(SIGCHLD, SIG_IGN); int id; id=fork(); if(id<0) { printf("fork error\n")

为什么程序中,常会用到signal(SIGCHLD,SIG_DFL)

为什么程序中,常会用到signal(SIGCHLD,SIG_DFL) 执行system函数时,SIGCHLD信号,最好被显示的: signal( SIGCHLD, SIG_DFL ) 一下,因为system函数中,使用到了fork(),waitpid.如果父进程忽略了SIGCHID信号,waitpid就没有不能得到子进程的SIGCHLD信号,那么,处理的返回值就会有问题.system的返回值也会有问题.通常的做法是: signal( SIGCHLD, SIG_DFL ); system( com

Method and apparatus for training a memory signal via an error signal of a memory

Described herein is a method and an apparatus for training a memory signal via an error signal of a memory. The method comprises transmitting from a memory controller a command-address (C/A) signal to a memory module; determining by the memory contro

信号(三)---早期signal函数和现代signal函数的一些对比

使用signal函数的一些缺点: 由于signal函数调用成功时会返回原来信号处理程序的指针,所以如果我想要利用signal函数来获取原先信号处理程序的指针的话,必须要先去改变其信号处理方式.如下图所示 在早期的signal函数的实现中,使用signal函数安装的信号处理函数只能使用一次:在第一次捕捉到该信号的时候,就去执行安装的信号处理函数,同时内核会将该信号的信号处理方式修改为默认方式.下次进程再次收到这个信号的时候,进程将会执行信号的默认动作.但是现在的signal函数的实现并不是这样的,

在Keil中做stm32的软件仿真,查看输出PWM波形时,在逻辑分析仪中规定IO口signal,出现&quot;unknow signal&quot;

文章源地址:http://blog.sina.com.cn/s/blog_dc9244010102vtn1.html 最近在学习STM32的PWM波输出,由于手中没有示波器,于是按照野火的教程使用软件仿真,使用MDK5自带的逻辑分析仪观察波形,前边一路顺利,在打开逻辑分析仪往里添加signal时,问题出现了——Unknown Signal!信号无法添加进去.在百度文库看到一篇关于MDK460相关问题的解决方案,于是我抱着试一试的态度,试了一试,结果挺好的,于是想到了和大家分享一下. 1.错误提示

Linux系统下mpi 编程出现:Signal: Segmentation fault, Signal code: Address not mapped

在Ubuntu(安装了mpich和openmpi)下MPI编程时,代码没问题,但是在mpirun运行的时候出现如下问题[ubuntu:04803] *** Process received signal *** [ubuntu:04803] Signal: Segmentation fault (11) [ubuntu:04803] Signal code: Address not mapped (1) [ubuntu:04803] Failing at address: 0x7548d0c [