关于使用管道实现父进程监听子进程状态的疑问

ilmare

原帖由 "gadfly" 发表：
大概明白你的意思了。你的意思就是说，是父通过管道写数据到子，同时有检测子的退出，对不对？

这不失为一种方法。

但是我觉得如果select仅仅用来检测子的退出，就没必要了，因为，
1.如果子主动关闭fd0，sel..........

   


呵呵，有人差不多明白我的意思了。

我看到的代码不是我贴出来的这么简单，但原理差不多就是这样的，主要是实现监听进程即父进程监听是否有子进程异常退出的情况。

采用select调用，可能是因为父进程并不需要向子进程写数据，正常情况下父进程是阻塞的，当有子进程异常退出时，父进程就会被激活，从而实现对子进程的监听控制。

gadfly

SIGCHLD会中断select的

gadfly

当然，如果select同时监控其它的连接，这种方式也不错。

只不过太cool，后续的人接手的话，是很难马上搞清楚意思的。

ilmare

原帖由 "gadfly" 发表：
当然，如果select同时监控其它的连接，这种方式也不错。

只不过太cool，后续的人接手的话，是很难马上搞清楚意思的。

   

是啊，我现在也没搞明白为什么子进程退出后，父进程的描述符fd[1]的状态会改变。你能解释一下吗？

gadfly

fieryfox的解释是对的呀。

我觉得fireryfox说的对。补充一点，你把父进程中的0互换1是一样的，结果是一样的。

进程退出的时候，会关闭所有的文件描述符，所以产生EOF。

ilmare

原帖由 "gadfly" 发表：
fieryfox的解释是对的呀。

   

原帖由 "fieryfox"]某些系统，如solaris其fd[0]和fd[1 发表：
同时打开为读写。
楼主的代码应该是想用管道的EOF来通知父进程。

   


但是为什么在最初情况下描述符fd[1]为读未准备，子进程退出后fd[1]变成读已准备呢？

我是这样理解的：在最初情况下由于将管道方向置为从父进程到子进程，父进程关闭管道的读端，子进程关闭管道的写端，此时对父进程来说fd[1]只能用来写数据，对子进程来说fd[0]只能用来读数据；子进程退出后，对父进程来说描述符fd[1]就不再受只能写数据而不能读数据的限制，因此select调用返回。另外，我觉得子进程退出应该不能在管道中产生EOF，因为对子进程来说写端已关闭，而描述符fd[0]应该与此时的父进程的描述符fd[1]一样受限制，只不过fd[0]只能用来读数据而不能写数据，而fd[1]只能写数据而不能读数据。不知道对不对。

gadfly

我还是认为我的理解是正确的。

其实，你client 手工close(fd[0]),不退出，也会产生这样的效果。

这就是因为EOF。而不是说因为什么限制而返回。也就是说client的fd0对应的父进程的fd1，形成一个读写管道。虽然fd0只是只读，但是关闭，会对对方发送EOF的信号或状态。其实原理和机制和socket的是一样的。

蓝色键盘

我来补充一点。

这个问题的关键是pipe后，系统对描述字是如何处理的。可以分为如下情况：

1、0为读打开，1为写打开。这是一般的情况。

我便是认为楼主是这种情况，当然你没有说明你的系统。为此，我说你的代码混乱，因为父进

程中希望select写，可是select参数监测的是读。

2、同时为读写打开。这是posix不建议的做法，但是一些系统是这么实现的。为了实现全双工

，posix加以使用流管道，有名pipe等。

如果楼主的是这种情况，那么我的指责是无知的，各位的置疑和批评是正确的。

至于为什么select能够返回的理由，gadfly的解释让我佩服！我不知道楼主现在是否明白。
如果还有些混淆的话，建议理解两个方面：
1、进程退出（包括异常）后，会关闭当年打开的描述字，可以参看exit(),_exit()和cleanup

例程，对此估计不难理解。
2、进程不退出，但是进程主动对pipe端口操作，例如write，read或close等。

wiserd

那么：
socketpair(AF_UNIX, SOCK_STREAM, 0, nSockfd);
有没有此类问题？

蓝色键盘

socketpair创建的是全双工的。除了读写外，其它的特点一般的讲和pipe类似（这里说得特点是和楼主的类似）。