问题描述
我一直在阅读 libev的源代码，迷迷糊糊对此评论:
I've been reading through libev's source code and stumbled upon this comment:
我已经在一些现代linux内核上使用epoll(直接使用syscalls)进行了一些测试，但无法复制.我看不到无声消失的fds"的任何问题.有人可以详细说明一下，还是告诉我这是否仍然是一个问题?
I've been doing some tests with epoll (directly using syscalls) on some modern linux kernel and I couldn't reproduce it. I didn't see any problem with "silently disappearing fds". Could someone elaborate on this and tell me if it's still an issue?
推荐答案
那里的文字比较模糊，但是我想只是如果描述符在其他位置close d，它就会从集合中静默删除.从Linux联机帮助页中， epoll(7):
This is rather vague text there, but I guess it is just that if the descriptor is closed elsewhere, it is silently removed from the set. From Linux manpages, epoll(7):
A6 是，但是请注意以下几点.一份文件 描述符是对打开文件的引用 说明(请参见open(2)).每当描述符 通过dup(2)，dup2(2)，fcntl(2)复制 F_DUPFD或fork(2)，一个新的文件描述符引用- 响到相同的打开文件描述为cre‐ 吃了打开的文件描述继续 一直存在，直到所有引用它的文件描述符 已关闭.文件描述符已删除 仅在所有文件之后才从epoll设置 引用底层打开文件的描述符 说明已关闭(如果 使用显式删除描述符 epoll_ctl(2) EPOLL_CTL_DEL).这意味着 即使在文件描述符中 epoll集已关闭，可能会报告事件 如果其他文件描述了该文件描述符 指同一个基础文件的tor 说明保持打开状态.
A6 Yes, but be aware of the following point. A file descriptor is a reference to an open file description (see open(2)). Whenever a descriptor is duplicated via dup(2), dup2(2), fcntl(2) F_DUPFD, or fork(2), a new file descriptor refer‐ ring to the same open file description is cre‐ ated. An open file description continues to exist until all file descriptors referring to it have been closed. A file descriptor is removed from an epoll set only after all the file descriptors referring to the underlying open file description have been closed (or before if the descriptor is explicitly removed using epoll_ctl(2) EPOLL_CTL_DEL). This means that even after a file descriptor that is part of an epoll set has been closed, events may be reported for that file descriptor if other file descrip‐ tors referring to the same underlying file description remain open.
因此，您有一个带fd 42的套接字.它获得close d，随后从epoll对象中移除.但是内核不会通过 epoll_wait通知libev.现在，使用fd = 42再次调用epoll_modify. epoll_modify不知道此文件描述符42是否与epoll对象中已有的文件描述符相同，或其他一些文件描述符编号42被重用的文件描述.
So you have a socket with fd 42. It gets closed, and subsequently removed from the epoll object. But the kernel doesn't notify the libev about this through epoll_wait. Now the epoll_modify is called again with fd = 42. epoll_modify doesn't know whether this file descriptor 42 the same that already was in the epoll object or some other file description with the file descriptor number 42 reused.
有人可能会说这些评论很夸张，而libev API的设计在这里是错误的.
One could also argue that the comments are just ranting and the design of the libev API is at fault here.
这篇关于Epoll:它会无声删除fds吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！