public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: Kev <klmitch@MIT.EDU>
Cc: Arjen Wolfs <arjen@euro.net>,
	coder-com@undernet.org, feedback@distributopia.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork  performance
Date: Sun, 03 Feb 2002 19:25:03 -0800	[thread overview]
Message-ID: <3C5DFF0F.3B5EFFC0@kegel.com> (raw)
In-Reply-To: <200202040255.VAA20532@multics.mit.edu>

Kev wrote:
> 
> > > I don't understand what it is you're saying here.  The ircu server uses
> > > non-blocking sockets, and has since long before EfNet and Undernet branched,
> > > so it already handles EWOULDBLOCK or EAGAIN intelligently, as far as I know.
> >
> > Right.  poll() and Solaris /dev/poll are programmer-friendly; they give
> > you the current readiness status for each socket.  ircu handles them fine.
> >
> > /dev/epoll and Linux 2.4's rtsig feature, on the other hand, are
> > programmer-hostile; they don't tell you which sockets are ready.
> > Instead, they tell you when sockets *become* ready;
> > your only indication that those sockets have become *unready*
> > is when you see an EWOULDBLOCK from them.
> 
> If I'm reading Poller_sigio::waitForEvents correctly, the rtsig stuff at
> least tries to return a list of which sockets have become ready, and your
> implementation falls back to some other interface when the signal queue
> overflows.  It also seems to extract what state the socket's in at that
> point.
> 
> If that's true, I confess I can't quite see your point even still.  Once
> the event is generated, ircd should read or write as much as it can, then
> not pay any attention to the socket until readiness is again signaled by
> the generation of an event.  Sorry if I'm being dense here...

If you actually do read or write *until an EWOULDBLOCK*, no problem.
If your code has a path where it fails to do so, it will get stuck,
as no further readiness events will be forthcoming.  That's all.
- Dan

  reply	other threads:[~2002-02-04  3:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-29 18:00 PROBLEM: high system usage / poor SMP network performance Dan Kegel
2002-01-29 20:09 ` Vincent Sweeney
2002-01-31  5:24   ` Dan Kegel
     [not found]     ` <001d01c1aa8e$2e067e60$0201010a@frodo>
2002-02-03  8:03       ` Dan Kegel
2002-02-03  8:36         ` Andrew Morton
2002-02-04 14:57           ` [Coder-Com] " Darren Smith
2002-02-04 17:41             ` Aaron Sethman
2002-02-04 18:11               ` Darren Smith
2002-02-04 18:30                 ` Aaron Sethman
2002-02-04 18:48                   ` Kev
2002-02-04 18:59                     ` Aaron Sethman
2002-02-04 18:53                   ` Doug McNaught
2002-02-08 22:11                 ` James Antill
2002-02-12 18:48           ` Vincent Sweeney
2002-02-03 19:22         ` Kev
     [not found]       ` <5.1.0.14.2.20020203173247.02c946e8@pop.euronet.nl>
2002-02-03 19:16         ` [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork performance Dan Kegel
2002-02-04  0:07           ` Kev
2002-02-04  0:37             ` Dan Kegel
2002-02-04  0:59               ` Aaron Sethman
2002-02-04  1:16                 ` Dan Kegel
2002-02-04  1:30                   ` Aaron Sethman
2002-02-04  1:38                     ` Dan Kegel
2002-02-04  4:38                       ` Aaron Sethman
2002-02-04  5:35                         ` Dan Kegel
2002-02-04  5:43                           ` Aaron Sethman
2002-02-04  6:11                 ` Daniel Phillips
2002-02-04  6:26                   ` Aaron Sethman
2002-02-04  6:29                     ` Daniel Phillips
2002-02-04  6:39                       ` Aaron Sethman
2002-02-04  2:55               ` Kev
2002-02-04  3:25                 ` Dan Kegel [this message]
2002-02-04  4:47                   ` Aaron Sethman
2002-02-04  5:10                   ` Kev

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=3C5DFF0F.3B5EFFC0@kegel.com \
    --to=dank@kegel.com \
    --cc=arjen@euro.net \
    --cc=coder-com@undernet.org \
    --cc=feedback@distributopia.com \
    --cc=klmitch@MIT.EDU \
    --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