> Apparently, the Linux kernel associates epoll state with files in such > a way that the epoll state is shared across dup()'d fds. I'll read the > kernel source a little more to be sure of what's happening. I've > attached a variant of my test code to reproduce this. Thanks, Gilad, > for all your patience on this! > > Now the last step is to figure out: what is the right fix here? I'm > probably going to need to sleep on that one. My current sense is that > we will not be able to support every possible usage of dup()'d fds in a > single epoll-based event base, and that we'll need to amend the docs to > say so, but that it should be possible to support the usage that > Gilad's current application is doing. But more thought is needed here, > and I probably ought to peruse the kernel source a little more to make > sure that dup+epoll works the way I'm guessing it works. >
I should probably add that the reason for duplicating the file descriptor in the first place had to do with an issue I had a year ago. My code would create an event (I believe it was libevent 1.4) on a socket and then hand the socket descriptor to libcurl. At some later point curl would terminate the connection, close the socket and notify my code. My code at that point attempted to deleted the event, but epoll failed on account that the file descriptor was already closed. After discussing this issue on both this list and the kernel mailing list, I fixed that scenario by creating event on a duplicated fd, and handing curl the original one. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
