Это немного запутанно.
Когда вы открываете новый файл, создаются два объекта. Один, если дескриптор файла в ядре. Другой - файловый дескриптор, номер, ссылающийся на этот дескриптор файла.
Хотя я не знаю точно, что произойдет с epoll fd, я предполагаю, что это то же самое, что и с любыми другими дублирующими файлами, и это то, что они являются одним и тем же файловым дескриптором.
Для намека, что этот отрывок из страницы epoll(2) человека может помочь:
Q6 Будет ли закрытие дескриптора файла причина его удаления из всех наборов Epoll автоматически?
A6 Да, но помните следующее. Дескриптор файла является ссылкой на описание открытого файла (см. open(2)). Всякий раз, когда дескриптор продублированы через dup(2), dup2(2), fcntl(2)F_DUPFD или fork(2), новый дескриптор файла ссылается на то же описание открытого файла создается. Открытое описание файла продолжается до все дескрипторы файлов, ссылающиеся на него, были закрыты. Дескриптор файла удаляется из набора epoll только после того, как все файлы дескрипторы, ссылающиеся на описание открытого файла , были закрыты (или до того, как дескриптор явно удален с использованием epoll_ctl(2)EPOLL_CTL_DEL).
Это означает, что даже после того, как файл дескриптор, который является частью набора epoll, был закрыт, события могут сообщаться для этого файлового дескриптора, если другие файлы дескрипторы, ссылающиеся на одно и то же основное описание файла , остаются открытыми.
Таким образом, в то время как я не проверил это сам, я предполагаю, что dup не позволит дублировать список фильтров в Epoll в любом случае. Оба fd s будут ссылаться на один и тот же дескриптор файла. Любое изменение фильтра, сделанное для одного, будет отражено в другом.
К сожалению, поскольку API API не знает о запросе списка фильтров epoll, это означает, что у вас нет возможности делать то, что вы хотите, не дожидаясь отслеживания с самого начала.