Epoll handling of multiple non-unique io_waits?

[ioquatix]

@machty you found a great flag for kqueue to handle this, is there anything similar for epoll?

[machty]

I don't really have a good Linux setup to try this out (curious what your dev setup is like to try these different platforms.. VMware or something?)

But, from the man pages for epoll:

   Questions and answers
       0.  What is the key used to distinguish the file descriptors
           registered in an interest list?

           The key is the combination of the file descriptor number and
           the open file description (also known as an "open file
           handle", the kernel's internal representation of an open
           file).

       1.  What happens if you register the same file descriptor on an
           epoll instance twice?

           You will probably get EEXIST.  However, it is possible to add
           a duplicate (dup(2), dup2(2), fcntl(2) F_DUPFD) file
           descriptor to the same epoll instance.  This can be a useful
           technique for filtering events, if the duplicate file
           descriptors are registered with different events masks.

So, unlike kqueue, epoll doesn't seem to have a udata that can optionally be part of the key. That said, you can dup the fd and add it to the same epoll instance as a separate entry. I can imagine some solution of a file descriptor "pool" where Fibers can check out an FD so that it can be added to epoll, and if another Fiber also wants to add that FD to epoll, the pool would let them check out a dupd copy of that FD. Seem plausible?

[ioquatix]

I'm already using dup on EEXIST but I thought it was a total hack. At least this confirms it's "acceptable".

[machty]

Is there a potential issue where if the user calls .close on the IO, it doesn't fully close because it's been duped by the epoll selector?

[ioquatix]

This is a reasonable concern. I believe on every code path out of io_wait we close the duped file descriptor. so I believe it should be okay.