最近发现在一个服务端程序中, 父进程调用了listen函数后, 将服务端的socket句柄放在共享内存中, 随后fork出若干个子进程, 之后退出了...

子进程的处理函数中先对共享内存中的监听句柄调用了accept接受客户端的链接, 随后是一堆业务处理的函数....

这个程序采用的是长连接的机制, 按本人的理解, 子进程中一旦断开了连接, 由于调用listen的主进程已经退出, 那么重新accept将会一直阻塞

但是奇怪的是子进程发生通讯异常时断开, 重新accept竟然可以接收到客户端的connect请求, 并且我用lsof -p命令查看子进程时, 竟然发现每个子进程都在监听指定的端口...

请问有哪位大侠知道这是为什么吗? 难道一个listen调用后只要服务端的socket句柄不关闭, 即使主进程退出了也依然可以从监听队列中取到connect请求吗?

叩谢....

你先搞清楚socket和accept返回的2个fd分别是干吗的，这样就能理解了。
socket返回一个fd，为后续建立监听队列做准备。
而Listen函数使socket处于被动的监听模式，并为该socket建立一个输入数据队列，将到达的服务请求保存在此队列中，直到程序处理它们。
处理它的函数就是accept咯，它会处理连接请求，并返回一个用于现有tcp连接的fd.

其实你看看客户端connect为何是阻塞就知道了，在你accept之前，connect是一直阻塞的。Listen只是服务器的一个中间处理过程。

具体的看看这里：
http://blog.csdn.net/hairetz/archive/2009/05/29/4223219.aspx

其实都是些基础只是来的。

只要用来监听的文件描述没有关闭，这个文件描述符就一直在监听connect请求
你所说的异常关闭，关闭的是连结文件描述符（accept返回的用与通信的文件描述符），而不是监听用的文件描述符（bind函数设置的文件描述符），所以这个文件描述符还是在监听的。
不知道我的理解对不对，仅供参考