RE: epoll design problems with common fork/exec patterns

David Schwartz
2007-10-28T21:04:56Z

Eric Dumazet wrote:

> Events are not necessarly reported "by descriptors". epoll uses an opaque
> field provided by the user.
>
> It's up to the user to properly chose a tag that will makes sense
> if the user
> app is playing dup()/close() games for example.

Great. So the only issue then is that the documentation is confusing. It
frequently uses the term "fd" where it means file. For example, it says:

Q1 What happens if you add the same fd to an
epoll_set
twice?

A1 You will probably get EEXIST. However, it is
possible
that two threads may add the same fd twice. This is
a
harmless condition.

This gives no reason to think there's anything wrong with adding the same
file twice so long as you do so through different descriptors. (One can
imagine an application that does this to segregate read and write operations
to avoid a race where the descriptor is closed from under a writer due to
handling a fatal read error.) Obviously, that won't work.

And this part:

Q6 Will the close of an fd cause it to be removed from
all
epoll sets automatically?

A6 Yes.

This is incorrect. Closing an fd will not cause it to be removed from all
epoll sets automatically. Only closing a file will. This is what caused the
OP's confusion, and it is at best imprecise and, at worst, flat out wrong.

DS

PS: It is customary to trim individuals off of CC lists when replying to a
list when the subject matter of the post is squarely inside the subject of
the list. If the person CC'd was interested in the list's subject, he or she
would presumably subscribe to the list. Not everyone wants two copies of
every post. Not everyone wants a personal copy of every sub-thread that
results from a post they make. In the past few years, I've received
approximately an equal number of complaints about trimming CC's on posts to
LKML and not trimming CC's on such posts.