To be a better coder
分类: WINDOWS
2018-10-30 13:58:40
点击(此处)折叠或打开
子进程忘记了退出,那么当有客户发起链接时,服务端出现了以下情况:
当时觉得很奇怪,按理说就是子进程没有退出也应该和父进程一样阻塞在select上啊,为什么会出现死循环。又来检查了select的返回值,如下:
点击(此处)折叠或打开
从新启动服务端,当有客户链接时,服务端显示如下:
这下我们知道其中的原因了,因为监听套接字描述符在子进程中已经close,所以对一个close的描述符select会直接返回错误,从而子进程不会阻塞在select,造成死循环。
我们也可以如下验证,在子进程中不close监听套接字:
点击(此处)折叠或打开
再次运行服务端,并从客户端发起链接,服务度显示如下:
我们发现这次子进程阻塞在了select,因为被select的套接字没有close。
但是这里面有个问题,有人会问父进程也打开了监听套接字,fork后监听套接字的打开引用计数会变为2,子进程close只会使监听套接字的打开引用计数减1,并不会真正关闭套接字,那为什么子进程就不能select呢?
这个问题要从VFS角度说明,即父子进程描述符、打开文件表、FILE(socket)对象之间的关系。
可以看到,父子进程有各自的打开文件表(files_struct),但是共享底层的FILE对象,而close的效果就是使FILE对象的引用计数减一,也就是解除了一个描述符和FILE对象的关联。对于子进程,当调用close后,子进程中的listenfd对应的指针下标已经不再和对应监听套接字对象相关联了,所以从子进程角度来说这个listenfd已经是个无效的描述符,不能再对其进行操作了。
补充:以上select的例子同样适用于accept,当子进程close(listenfd)后没有exet退出,再次执行accept同样会造成Bad file descriptor。例如如下tcp服务端程序:
点击(此处)折叠或打开
当客户端连接后效果如下图所示。