2

When you add a fd to an epoll set, you can associate some state with it by using 'struct epoll_event.data'. When epoll reports an event on the fd, it, of course, returns the associated data to the user along with the event. This implies that the epoll set is maintaining a mapping between fds and associated state.

Let's say that I am setting epoll_event.data.ptr to some state that I dynamically allocated and at some point in future, I want to remove the fd from the epoll set and consequently free the memory that I set in ptr earlier.

As far as I can tell, there is no programmatic way for me to look up the state associated with a fd in an epoll set to accomplish the above. I am currently maintaining my own mapping between fds and associated state. I understand that maintaining this mapping doesn't require much memory but I still feel like it is not very efficient to maintain the same mapping in two different places.

So my question is: Is there a way to retrieve the state associated with a fd in an epoll set?

jxh
  • 69,070
  • 8
  • 110
  • 193
Akhi
  • 190
  • 1
  • 1
  • 6
  • You could keep your own copy of states you added to the epoll set. Every time an event fires, you can remove it from your local copy, too, and thus keep the two in sync. – Kerrek SB Jan 10 '17 at 10:07
  • Can you just close the fd you want to remove, and let epoll_wait return you that fd, and your data, with an ERR/HUP/INVAL state? – Useless Jan 10 '17 at 10:54
  • Good idea but alas I do not want to close the fd. I need to use level triggering and in certain situations, I don't care if the fd is readable. I'll try to rework my logic so that I never have to remove the fd from the epoll set. – Akhi Jan 10 '17 at 11:09

1 Answers1

2

No, there is no way to retrieve the state on demand. The associated state is only returned if there is an epoll_wait wake up for the descriptor.

Reading back on some old technical forums, this same issue was notably debated in a thread titled Clumsy interface of epoll. Basically, it was argued that keeping the mapping in user space code is pretty much required anyway, although an EPOLL_CTL_GET interface was proposed as a possible solution.

Although it was not explicitly mentioned in the thread as a reason, one thing to consider about registered descriptors is that the deregistration occurs automatically if the descriptor is closed.† Unfortunately, there is no "descriptor was implicitly deregistered" wakeup from epoll_wait.

I see that the EPOLL_CTL_GET interface was hypothetically presented as a reason to leave the events argument non-const in the thread epoll_ctl and const correctness.

† Assuming all its duplicates are closed as well.

Community
  • 1
  • 1
jxh
  • 69,070
  • 8
  • 110
  • 193
  • Thanks for the link. It was an interesting and an amusing read. I'm happy to see that I was not the first one to come up with this issue. Out of curiosity, how did you find the email thread? I had tried google search before posting the question but maybe my google-fu wasn't good enough. – Akhi Jan 12 '17 at 17:52
  • I had originally commented that you could propose `EPOLL_CTL_GET`, but then I did a search to see if it had ever been proposed before. – jxh Jan 12 '17 at 17:58