linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Varsanyi <e0216@foo21.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: epoll vs stdin/stdout
Date: Mon, 7 Jul 2003 14:47:36 -0500	[thread overview]
Message-ID: <20030707194736.GF9328@srv.foo21.com> (raw)
In-Reply-To: <Pine.LNX.4.55.0307071153270.4704@bigblue.dev.mcafeelabs.com>

On Mon, Jul 07, 2003 at 11:57:02AM -0700, Davide Libenzi wrote:
> Events caught by epoll comes from a file* since that is the abstraction
> the kernel handles. Events really happen on the file* and there's no way
> if you dup()ing 1000 times a single fd, to say that events are for fd = 122.

It is useful/mildly common at the app level to want to get read events
for fd0 and write avail events for fd1. An app that might want to deal
with reads from stdin in one process and writes to stdout in another
(something like "team" perhaps) would have trouble here too.

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.

I considered:
	- using a second epoll object just for one of the fd's (to inspire
	  delivery of the event to 2 wait queues in the kernel); a little
	  ugly because of need to stack another epfd under the main one
	  just for stdout write events

	- select() on (0, 1, epfd) and just use epoll with a timeout of 0
	  when select fires to gather bulk of events; morally similar to 
	  previous but using select (which I want to just get away from)

	- make the app use stdin as its output (this is what I ended up doing);
	  breaks redirection of stdout but that doesn't matter to this app

Thanks,
-Eric Varsanyi

  reply	other threads:[~2003-07-07 19:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 15:48 Eric Varsanyi
2003-07-07 18:57 ` Davide Libenzi
2003-07-07 19:47   ` Eric Varsanyi [this message]
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
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

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=20030707194736.GF9328@srv.foo21.com \
    --to=e0216@foo21.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: epoll vs stdin/stdout' \
    /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

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).