fork() & 僵尸进程

上周,项目里需要一个视频转发工具,我用libvlc完成了一个,大致流程如下:

(1)主进程监听指定端口,接收转发请求;

(2)验证请求合法性后,主进程fork一个子进程,在子进程中启动vlc进行转发。

 

但调试时发现了一个小问题:

fork出子进程后,在父进程中没有调用waitpid,在子进程退出后, 父进程没有为它“收尸”。于是乎,子进程虽然退出了,但进程号在系统历仍然存在,变成了臭名昭著的“僵尸进程”。

问题的根源在于:父进程没有调用waitpid来监测子进程的活动状况,关于waitpid能干什么,请搜索之。。。

但是:父进程是单线程(称为监听线程),主要干一件事,那就是调用socket的recvfrom(),阻塞的监听网络请求; 因此,不可能用来调用waitpid来为子进程收尸。

 

有四个办法解决: 

(一)在父进程监听线程中给socket设超时,每次超时后就调用waitpid(使用NOHANG参数,免得主进程被挂住)来查看一下子进程的状态。如果子进程退出了,就为它收尸;否则就继续recrfrom,监听请求。

主要问题有两个:(1)子进程退出后,必须等到recvfrom超时后,父进程才会调用waitpid,才会知道子进程已经退出了,从而为它收尸;

(2)虽然调用waitpid时间很短,但也会造成recvfrom()暂时中断;如果这段时间刚好有网络请求过来,父进程就很可能接收不到该请求,造成服务无响应,这种情况必须避免。

 

(二)父进程中再开一个线程(简称监测线程),使用waitpid()专门检测子进程的状态(不使用NOHANG参数,一直挂在waitpid上),实际上我在录制程序中就是这么干的(主要是为了实现子进程崩溃时,由父进程自动重启子进程)。

问题在于:监测线程中检测到子进程退出后,我还需要从父进程中查找子进程列表,确认是那一路节目退出了;这样就必须加锁,因为监听线程随时可能访问子进程列表。

这样一来,就遇到了棘手的问题:多线程+加锁+fork()多进程,这正是我尽力避免的一种情况 。

 

(三) 在父进程中忽略SIGCLD信号,就不会产生僵尸进程了,具体如下:

 signal(SIGCLD, SIG_IGN); /* now I don't have to wait()! */  

但是,当我在子进程中启动libvlc 进行视频转发时,发现无法启动vlc,经过跟踪,确认子进程在初始化libvlc时挂住了:

_vlcinstance = libvlc_new(sizeof (vlc_args) / sizeof (vlc_args[0]), vlc_args, &_vlcexcep); //Calculation character space

具体就是调用libvlc_new()时,原因未知,推测可能是libvlc内部对该信号量做了某种处理,导致挂死。

 

 (四)父进程中,连续fork()两次,立即退出子进程,使孙进程成为“孤儿进程”,被系统的init进程管理;这样,孙进程退出时,init进程会负责为它收尸,就不会产生僵尸进程了。

 虽然听起来不错,但总归有点投机取巧。

 

最后权衡了一下,还是选择了方法(二)来解决此问题。

原因是:

(1)我希望将自动重启机制也加进来。由于vlc本身并不是很稳定,在运行时可能会崩溃;而 我们的转发服务不能停。

因此,如果主进程发现某一路子进程退出了,立即检查是否需要重启(有多种退出原因,可能是主动停止的),如果需要,就查找是哪一路节目,然后立即fork()出一个子进程进行转发。

(2)至于多线程加锁的问题, 后来确认了一下,实际上并不存在此问题。因为在父进程监测线程中并不需要对子进程列表进行写操作,只需要查询即可.

 

 

 

 

 

posted @ 2012-01-13 17:27    阅读(625)  评论(0编辑  收藏  举报