RE: epoll design problems with common fork/exec patterns

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <dada1@...>
Cc: Linux-Kernel@Vger. Kernel. Org <linux-kernel@...>
Date: Sunday, October 28, 2007 - 5:04 pm

Eric Dumazet wrote:


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.


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
epoll design problems with common fork/exec patterns, Marc Lehmann, (Sat Oct 27, 2:22 am)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Sat Oct 27, 12:59 pm)
RE: epoll design problems with common fork/exec patterns, David Schwartz, (Sun Oct 28, 12:47 am)
RE: epoll design problems with common fork/exec patterns, Davide Libenzi, (Sun Oct 28, 2:48 pm)
RE: epoll design problems with common fork/exec patterns, David Schwartz, (Sun Oct 28, 5:04 pm)
RE: epoll design problems with common fork/exec patterns, Davide Libenzi, (Mon Oct 29, 2:55 pm)
Re: epoll design problems with common fork/exec patterns, Michael Kerrisk, (Tue Feb 26, 11:13 am)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Tue Feb 26, 2:51 pm)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Wed Feb 27, 3:35 pm)
Re: epoll design problems with common fork/exec patterns, Michael Kerrisk, (Thu Feb 28, 9:12 am)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Thu Feb 28, 3:23 pm)
Re: epoll design problems with common fork/exec patterns, Michael Kerrisk, (Fri Feb 29, 11:46 am)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Fri Feb 29, 3:19 pm)
Re: epoll design problems with common fork/exec patterns, Michael Kerrisk, (Fri Feb 29, 3:54 pm)
Re: epoll design problems with common fork/exec patterns, Michael Kerrisk, (Thu Feb 28, 9:23 am)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Thu Feb 28, 3:34 pm)
Re: epoll design problems with common fork/exec patterns, Willy Tarreau, (Sat Oct 27, 1:38 pm)
Re: epoll design problems with common fork/exec patterns, Davide Libenzi, (Sat Oct 27, 2:01 pm)