All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Carlo Wood <carlo@alinoe.com>
Subject: re: kqueue, kevent - kernel event notification mechanism
Date: Wed, 05 Dec 2001 23:33:06 -0800	[thread overview]
Message-ID: <3C0F1F32.C235F9CC@kegel.com> (raw)

Carlo Wood <carlo@alinoe.com> wrote:
> are there any plans to implement the kqueue, kevent system calls
> in the linux kernel?
> 
> There is no substitute for them currently; select() and poll()
> both suffer from dramatic cpu usage when a daemon is loaded with
> a few thousand clients.

There is already an efficient mechanism - although with a very
different interface - in the 2.4.x kernel: edge triggered readiness
notification via realtime signals.  This matches one style of
kqueue()/kevent() usage.  For those who prefer level-triggered
readiness notification (more like what poll() gives you),
I have written a wrapper class that papers over the difference
efficiently, at the cost of making the app tell my class about
all the EWOULDBLOCKs it gets.
See http://www.kegel.com/c10k.html#nb.sigio for details.
I don't particularly like signals for this, as they're a
bit heavyweight, and the global signal queue is a bit precious,
but it does benchmark well, even for thousands of clients.

(That page also describes kqueue etc. and the experimental
/dev/poll drivers.)
- Dan

             reply	other threads:[~2001-12-06  7:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-06  7:33 Dan Kegel [this message]
2001-12-06 14:28 ` kqueue, kevent - kernel event notification mechanism Carlo Wood
  -- strict thread matches above, loose matches on Subject: below --
2001-12-06  0:38 Carlo Wood
2001-12-06  0:57 ` Alan Cox
2001-12-06  5:48   ` Benjamin LaHaise

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=3C0F1F32.C235F9CC@kegel.com \
    --to=dank@kegel.com \
    --cc=carlo@alinoe.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.