From: Davide Libenzi <firstname.lastname@example.org>
To: Jamie Lokier <email@example.com>
Cc: Eric Varsanyi <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>
Subject: Re: epoll vs stdin/stdout
Date: Mon, 7 Jul 2003 15:11:23 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.firstname.lastname@example.org> (raw)
On Mon, 7 Jul 2003, Jamie Lokier wrote:
> Eric Varsanyi wrote:
> > Epoll's API/impl is great as it is IMO, not suggesting need for change, I was
> > hoping there was a good standard trick someone worked up to get around
> > this specifc end case of stdin/stdout usually being dups but sometimes
> > not. Porting my event system over to use epoll was easy/straightforward
> > except for this one minor hitch.
> Easy: if it's a read event, it's stdin; if it's a write event, it's stdout :)
> You've raised an interesting problem. It is easy to fix this in the
> specific case of stdin/stdout, however what happens when your process
> is passed a pair of fds from some other process (or more than one
> process, using AF_UNIX), and told to read one and write the other?
> What happens when you have 10 fds from different sources, some for
> reading and some for writing (quite typical in a complex server)?
> With the epoll API, your process has to know whether any paids or fds
> correspond to the same file *, in order to decide whether to register
> one interested in READ+WRITE or two interests separately.
> Unfortunately I cannot think of a way for a process to know, in
> general, whether two fds that it is passed correspond to the same file
> *. Well, apart from trying epoll on it and seeing what happens :/
> Perhaps this indicates the epoll API _is_ flawed. Epoll maintains
> this state mapping:
> file * -> (event mask, event states)
> when it ought to maintain this:
> (file *, event type) -> event state
> In other words, perhaps epoll should be keeping registered interest in
> read events and registered interest in write events completely
It has to keep (file*, fd) as hashing key. That will work out just fine.
> I suspect changing the API to do that wouldn't even break any of the
> existing apps.
> Davide, what do you think?
Not even thinking changing the API since it'll break existing apps. The
above trick will do it. Going to test it ...
next prev parent reply other threads:[~2003-07-07 22:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-07 15:48 epoll vs stdin/stdout Eric Varsanyi
2003-07-07 18:57 ` Davide Libenzi
2003-07-07 19:47 ` Eric Varsanyi
2003-07-07 20:03 ` Jamie Lokier
2003-07-07 20:18 ` Miquel van Smoorenburg
2003-07-07 21:20 ` H. Peter Anvin
2003-07-07 22:11 ` Davide Libenzi [this message]
2003-07-08 0:24 ` Jamie Lokier
2003-07-08 0:23 ` Davide Libenzi
2003-07-07 22:12 ` Davide Libenzi
2003-07-07 23:26 ` Davide Libenzi
2003-07-08 0:32 ` Jamie Lokier
2003-07-08 0:32 ` Davide Libenzi
2003-07-08 0:52 ` Jamie Lokier
2003-07-08 1:13 ` Davide Libenzi
2003-07-08 12:34 ` Jamie Lokier
2003-07-08 13:51 ` Jamie Lokier
2003-07-08 15:20 ` Davide Libenzi
2003-07-08 15:46 ` Eric Varsanyi
2003-07-08 15:42 ` Davide Libenzi
2003-07-08 16:02 ` Eric Varsanyi
2003-07-08 17:06 ` Davide Libenzi
2003-07-08 18:40 ` Eric Varsanyi
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).