> > Here is the chain of events I was able to identify > > - An event for fd 14 is created > > - At some later point, my code deletes the event. strace does not > show > > a call to epoll_ctl to delete fd 14 from the set. > > - fd 14 is closed by my code > > - Shortly afterwards, there is a call to epoll_ctl to delete fd 14 > > - The call fails, of course, and a libevent warning says "DEL was > > unnecessary". The comment in that place in the code says "... that's > > fine too ... " > > - It's not fine. AFAIK, since the file descriptor is closed, epoll > > did not actually remove it > > - Further down the road, attempts to add fd 14 fail since epoll did > > not remove fd 14 in the first place. > > > > It seems like libevent delays the call to epoll_ctl, and by the time > > it actually does that, it's too late. > > But that's not how epoll behaves, I think. As near as I can tell, > closing an fd does indeed remove it from the fds watched by an epoll, > and so you can indeed re-add a new file with the same fd. > > I am basing this on actual testing, with the attached test code. It > adds a file to an epoll_fd, then closes the file, then arranges for a > new file to get made with the same epoll_fd, then adds the new file. > It does not get an EEXIST for me. (I tried this on a 2.6.26 kernel and > on a 2.6.34 kernel.) If you can come up with a setup where that > sequence of events gives an EEXIST, or if you can tweak the test here > until it gives an EEXIST, that would help figuring out how the sequence > of events described above could cause an EEXIST. > Your code indeed did work also on my kernel, which lead me to digging in different directions, but with no real results. I suspect the issue has to do with multiple events on the same fd being handled when applying a set of changes, but that's only a hunch. I do know that when I force libevent to use select I don't see any issues. Any chance you can make something out of the attached log ? Thanks
Attachment:
libevent.log
Description: Binary data