Davide Libenzi wrote:
> > 2. When process A sends an fd to process B, the events will appear
> > in process B _iff_ the fd number in B happens to be the same
> > value as in process A. (Without your patch, the events will always
> > appear in process B).
> >
> > Furthermore, when process B dups the fd or passes it elsewhere,
> > events will appear if the new fd happens to be the same as the
> > original fd number in A.
> >
> > The only correct application code in this case is to use
> > EPOLL_CTL_DEL in A and EPOLL_CTL_ADD in B, although it is
> > confusing because you'll have programs which _sometimes_ work
> > without that.
>
> This is false.
Actually it's true :)
> Is like saying that :
> [...]
> is a memory leak ;)
Well, yeah :)
You'll have to document this loud and clear: anyone who closes, dup2s
over or passed an epoll-activated file descriptor _must_ use
EPOLL_CTL_DEL first, otherwise heisenbugs may eventually follow.
> > I guess what I'm saying is that hashing on fd number is quite simply
> > wrong. The fundamental object is the file *, that's how its meant to be.
>
> The architecture is all based on the file*, it is there that events shows
> up. The (file*, fd) key is a constraint.
Unfortunately I just thought of a real problem :(
What happens when process A sends (or forks) a dup of its fd 3 to
process B which also has it as fd 3, and both processes use epoll on
it? (This is a fairly common scenario, to have one process/thread
reading and the other writing a tty or socket). The two processes
will clash because they have the same (file *, fd) pair, yet there is
no way for them to know they are clashing.
With current epoll code this is a problem already, because keying on
(file *) alone is not enough. Unfortunately (file *,fd) key doesn't
fix this one.
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:27 EST