Messages in this thread | | | Date | Tue, 8 Jul 2003 13:34:21 +0100 | From | Jamie Lokier <> | Subject | Re: epoll vs stdin/stdout |
| |
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/
| |