[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: [Libevent-users] epoll erros



> > 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