On Fri, Feb 17, 2017 at 01:34:04PM -0500, Jason Baron wrote:
> >
> > kcmp over target set seems to be preferred since it gonna be a way
> > faster. But I think about fd-ref idea too. Thanks a huge!
> >
>
> I sort of like kcmp() for this as well maybe the epoll fd argument can be a
> pointer to something like:
>
> struct epoll_slot {
> int epfd;
> int slot;
> };
>
> Where 'epfd' is the epoll fd, and slot is just an index into the target fds
> associated with the epoll fd. That is, you would start from 0 and go up to
> n. When you reach the last one you get in -EBADSLT or something.
Yes, I think we can even extend the slot and pass it as a pointer to
target fd set which are to be tested.
> Regarding Andy's point of of not having a reference by some other means, I
> think you have to have it basically otherwise it would be removed from the
> epfd. I guess it could be being passed via a unix socket? But there must be
> a way to get at those anyways, in order to restore them.
Yes. But the file may be obtained from unix sock, then dup'ed and installed
and then this dup'ed file get closed but unix instance is still alive. And
then we need to figure out that it's unix socket from where original target
file came from.
> Also, in the initial patch this function can not restore all target epoll
> files:
>
> 'ep_find_tfd(struct eventpoll *ep, int tfd)'
>
> Because the 'target' file for an epfd is the pair: {fd, file}. Thus, you
> could have say two different 'target' files with the same fd number.
Yes, but if we would have _DUP'ed them (ie installed into caller context)
we can find out their order and restore properly I think.
Thanks for comments, I'll think about all them at the weekend or early
next week.
Cyrill
