<story><title>Epoll is broken – part 2/2</title><url>https://idea.popcount.org/2017-03-20-epoll-is-fundamentally-broken-22/</url></story><parent_chain></parent_chain><comment><author>int_19h</author><text>I always found it interesting that WinNT got this one right very early on (IOCP; first appeared in NT 3.5 in 1994), and thus avoided all these problems, and a series of subsequent APIs trying to correct them. The way you do &lt;i&gt;efficient&lt;/i&gt; asynchronous I&amp;#x2F;O in Win32 today is still the same as it was 20 years ago.&lt;p&gt;For those unfamiliar with that model, here&amp;#x27;s a brief description:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20101101112358&amp;#x2F;http:&amp;#x2F;&amp;#x2F;doc.sch130.nsc.ru&amp;#x2F;www.sysinternals.com&amp;#x2F;ntw2k&amp;#x2F;info&amp;#x2F;comport.shtml&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;web.archive.org&amp;#x2F;web&amp;#x2F;20101101112358&amp;#x2F;http:&amp;#x2F;&amp;#x2F;doc.sch130...&lt;/a&gt;&lt;p&gt;My understanding is that kqueue in FreeBSD is also conceptually similar, but I never had a chance to take a close look at that.</text></comment>
<story><title>Epoll is broken – part 2/2</title><url>https://idea.popcount.org/2017-03-20-epoll-is-fundamentally-broken-22/</url></story><parent_chain></parent_chain><comment><author>mbrumlow</author><text>From the man page...&lt;p&gt;&amp;gt;       Q6  Will closing a file descriptor cause it to be removed from all epoll sets automatically?&lt;p&gt;&amp;gt;       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  file  descriptor  is  duplicated  via  dup(2),  dup2(2),
&amp;gt;           fcntl(2)  F_DUPFD,  or fork(2), a new file descriptor referring to the same open file description is created.  An open file description continues to exist until all file descriptors refer‐
&amp;gt;           ring 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
&amp;gt;           before  if  the  file 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
&amp;gt;           may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open.&lt;p&gt;EDIT:&lt;p&gt;Lots of comments here seem to think this should be unexpected or is a bug. Closing a FD you are using is a bug. I think epoll does a fairly good job of letting the user know that it is watching the description and not the descriptor. Failing to read the man page for dup would also leave you in a blind spot. I have been writing code for linux a while now and I did not think it was any secret that a file is still open until all of the fds pointing to it are closed. That is why you have to take care and close your duplicated fds at the right time otherwise you will end up with file handles leaking. The example code provided illustrates this perfectly.&lt;p&gt;As a side note using dup2 to get your original FD passed to epoll associated with the still open description from the duped fd should allow you to remove it.</text></comment>