Linux避免僵尸进程.docxVIP

僵尸进程的避免?网上搜一搜，基本上就是这样的三种方式：signal(SIGCHLD, SIG_IGN)，忽略SIGCHLD信号，这样子进程结束后，就不需要父进程来wait和释放资源fork两次，第一次fork的子进程在fork完成后直接退出，这样第二次fork得到的子进程就没有爸爸了（真可怜。。。），它会被自动过继给老祖宗init进程，init会负责释放它的资源，这样就不会由僵尸产生了对子进程进行wait，释放它们的资源。但是父进程一般没工夫在那里守着，等着子进程的退出，所以，一般使用信号的方式来处理，在收到SIGCHLD信号的时候，再临时用wait操作来释放它们的资源。?从个人角度，简单评价一下这三种方式：老爸不管儿子死活。父进程无法知晓子进程的退出情况。儿子自杀了，爷爷不管孙子。跟1一样，父进程无法知晓子进程的退出情况。老爸算是尽职了，儿子死了会给它火化（释放资源）。父进程可以知晓子进程的退出情况，不过处理比1和2麻烦。个人推荐第3种解决方法，这也引出了下面这样的一个问题。在《UNIX环境高级编程》10.8章节中有这样一段话：What happens if a blocked signal is generated more than once before the process unblocks the signal? POSIX.1 allows the system to deliver the signal either once or more than once. If the system delivers the signal more than once, we say that the signals are queued. Most UNIX systems, however, do not queue signals unless they support the real-time extensions to POSIX.1. Instead, the UNIX kernel simply delivers the signal once.这段话的意思是说：如果相同的信号在被在该进程解除对它的阻塞之前发生了多次，多数UNIX系统并不对该信号进行排队处理，也就是说，该信号将会被只递交一次。?这就是Linux中信号处理有一个特点，那就是，同一个信号被递交多次，如果第一个信号还在处理，那么后面的信号都会被丢弃，而不会进入队列中等待处理。如果我们只是简单的对这个信号处理，必然会丢失对后面相同信号的处理。?这个问题是在我写一个File Server的时候遇到的。这个文件服务器每接收一个Client请求，就fork一个进程对它进行处理。为了对这个Server进行压力测试，我在Client端生成了非常多的文件传输请求，同时为了测试Server的容错能力，我在这些请求生成后，按下Ctrl+C键中断了这些文件传输，发现每次执行这样的操作，Server端都会有大量的僵尸进程生成。研究了一整天，查阅了很多资料，并测试了多次，终于发现，原来这些僵尸进程的SIGCHLD信号被父进程给忽略了！没有对他们进行wait，从而导致了他们变成了僵尸进程！?下面举个简单的例子：[cpp:showcolumns]?view plaincopy·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150/*??*?main.cpp??*??*??Created?on:?Jun?17,?2011??*??????Author:?boyce??*/??#include?stdio.h??#include?stdlib.h??#include?unistd.h??#include?signal.h??#include?wait.h??#include?errno.h??int?num_clients?=?0;??int?dead_clients?=?0;??void?sig_chld_handler(int?sig)?{??????pid_t?pid;??????if?(sig?==?SIGCHLD)?{??????????pid?=?wait(NULL);??????????printf(A?child?dead,?current?child?number:?%d,?id:?%d/n,?++dead_clients,?pid);??????}??}??int?main(int?argc,?char?*