Messages in this thread | | | From | Bryan Donlan <> | Date | Wed, 16 Sep 2009 20:28:00 -0400 | Subject | Re: epoll and closed file descriptors |
| |
On Wed, Sep 16, 2009 at 8:23 PM, Gilad Benjamini <gilad@altornetworks.com> wrote: > Davide wrote: >> On Wed, 16 Sep 2009, Gilad Benjamini wrote: >> >> > I am running repeatedly into a scenario where epoll notifies >> userland of >> > events on a closed file descriptor. >> > I am running a single thread application, on a single CPU machine so >> > multiple threads isn't the issue. >> > >> > A sample set of events that I have seen >> > - File descriptor (13) for a socket is closed >> > - epoll_wait returns with no events. >> > - Several epoll related calls happen >> > - More than 20 seconds after the "close", epoll_wait finds an event >> on fd 13 >> > with EPOLLIN|EPOLLERR|EPOLLHUP. >> > - epoll_wait continues to report this event >> >> Epoll removes the fd from its container, when the last instance of the >> underlying kernel file pointer is released (or when you explicitly >> remove it with epoll_ctl(EPOLL_CTL_DEL)). >> If you continue to get the event, it means that someone else has an >> instance of the socket (that, looking at the events, saw a shutdown) >> open, >> by hence keeping the kernel object alive. >> If you don't want to see the events, just remove the socket from the >> epoll >> set before closing. >> Or, you remove the socket the first time you see an EPOLLHUP. >> >> >> >> - Davide > > I would, but epoll is preventing me from doing so. > Early in sys_epoll_ctl there are these lines > > file = fget(epfd); > if (!file) > goto error_return; > > Leaving me in a kind of dead lock
You could dup() the file descriptor before handing it to curl, and use your own copy for epoll operations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |