标签：动态 负载 连接 调用 执行 多进程并发 action 无法 可靠
以TCPServ 服务程序来说：
１）父进程:负责系统初始化，以及监听(listen),接受连接请求(accept);其中accept 默认阻塞调用。
２）每接受一个连接请求，动态新建(fork)一个子进程，任务完成或客户端断开，服务子进程需要退
出并收回系统资源。
３）根据linux的设计子进程的收回需要父进程参与(wait调用)，而此时附进程主要服务工作在监听
客户端连接请求，同时阻塞在(accept)调用,所以父进程自身是无法＂分身＂去做子进程回收调用。
４）现在的问题在于如何找到父进程的一个服务入口来完成进程回收调用。
方法有２：
１）利用信号机制，由操作系统产生软中断进入进程信号服务程序，执行子进程的回收调用。
在附进程(signal/sigaction)注册SIGCHILD信号，在信号处理函数中执行waitpid调用。
疑问：信号机制可靠吗？特别是应对大频率高负载的动态请求响应场景。
２）在父进程中启动一个新的独立线程pthread,专门负责执行回收调用，此时使用wait阻塞
调用比较合适，如果使用waitpid需要不停的循环等待。注意没有子进程时wait调用立即
返回失败。(父进程在fork子进程时候,可以做一个登记).
5）在很多情况下可以考虑用多线程并发代替多进程并发，省去了很多问题。
标签：动态 负载 连接 调用 执行 多进程并发 action 无法 可靠
原文地址：http://www.cnblogs.com/Esperanto/p/5983628.html
