On Tue, 8 Jul 2003, Jamie Lokier wrote:
> The old code didn't need to do it, because the events were registered
> for all the fd values pointing to a single file *. That's cool -
> that's exactly what anyone would expect. The point of dup2() is that
> the fds are equivalent, and share state (such as seek pointer).
>
> Now you have two strange (IMHO unclean) behaviours, that an
> application programmer needs to be aware of:
>
> 1. Duplicate fds don't share registered event state.
That's no unclean. It is the purpose of the patch. You can do now :
/* Remotely */
dup2(3, 4);
...
evt.data.ptr = mydata0;
evt.event = EPOLLIN | EPOLLET;
epoll_ctl(epfd, EPOLL_CTL_ADD, 3, &evt);
evt.data.ptr = mydata1;
evt.event = EPOLLOUT | EPOLLET;
epoll_ctl(epfd, EPOLL_CTL_ADD, 4, &evt);
And receive two different events for "mydata0" and "mydata1". That's what
you really link to.
> 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. Internally it's the file* that is the sink for events. So
they will receive events as long as the originator file* is alive.
> Oh, and:
>
> 3. It's almost a memory leak. Not quite because it's cleaned up
> eventually. But it looks and feels just like one.
This is false too. When the last user (file count) of the underneath file*
will drop it, it will be cleaned. This is not a memory leak in books where
I studied. Is like saying that :
int main() {
int i;
for (i = 0; i < 1000; i++)
open(...);
for (;;)
sleep(1);
return 0;
}
is a memory leak ;)
> 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.
- Davide
-
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 : Mon Jul 07 2003 - 22:00:31 EST