From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Felix von Leitner <felix-kerel@fefe.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: epoll_wait conflicts with man page
Date: Sun, 24 Nov 2002 20:46:33 +0000 [thread overview]
Message-ID: <20021124204633.GA27151@bjl1.asuk.net> (raw)
In-Reply-To: <20021124174635.GB16255@codeblau.de>
Felix von Leitner wrote:
> Also, I would move the
> "int fd" out of the union because it is universally useful to know the
> file descriptor without having to save it in the opaque data.
Hi Felix,
It is not possible for epoll itself to keep track of the fd number,
because some more advanced applications can change or duplicate fd
numbers (using dup(), dup2() or fcntl(F_DUPFD)), and in some cases its
possible for an event to arrive on an object which doesn't even _any_
valid fd value in the current process (e.g. while it's being passed
from one process to another through a unix domain socket, or with
certain uses of clone()).
While this might seem peculiar, it is the sort of thing that some
kinds of scalable server software do, for good reasons.
The only thing epoll could report would be the initially registered
"fd" value, which is meaningful for some applications but not
universally correct. As it would not always be correct, it is best
for the application itself to keep track of fd numbers. In practice,
all applications either use the `fd' field in the union (and no other
user-data), or a pointer in the union to a structure of flags and
other per-fd data, and that structure always includes a correct `fd'
value anyway for other reasons.
So, the API is perfect as it is :)
-- Jamie
prev parent reply other threads:[~2002-11-24 20:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-24 17:46 Felix von Leitner
2002-11-24 17:56 ` Davide Libenzi
2002-11-24 17:57 ` Davide Libenzi
2002-11-24 19:12 ` Davide Libenzi
2002-11-24 20:46 ` Jamie Lokier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021124204633.GA27151@bjl1.asuk.net \
--to=lk@tantalophile.demon.co.uk \
--cc=felix-kerel@fefe.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®