[ruby-talk:9690] Re: Non-blocking I/O?

> 
> "Ben Tilly" <[e-mail]> wrote:
> 
> > "Christian" <[e-mail]> wrote:
> > >
> > >This is very likely outside the interest of the discussion, but Linux's
> > >select() is extremely slow.
> >
> > Reference please?
> 
> Our server cluster is CPU limited (we have a 96Gb switch). Profiling showed
> that much of the time was spent waiting on select(). I sent a junior to
> investigate, he hacked the kernel and we got a speed increase. Not exactly a
> precise reference, but empirically accurate and my intentions were honest.
> Thanks for the networking reference.

One of the problems with select() is that the kernel keeps no state
of what descriptors a process is interested in between invocations
of select().  This means that each time, you've got to copy a bunch of
state across the user/kernel boundary and then back again to the user
process.

There's some interesting work which was done in FreeBSD to implement a
new primitive to communcate events between the kernel and user.  I'd
recommend that you look at a paper by the author on "kqueue" at
http://people.freebsd.org/~jlemon/ for some details.  It's a very
interesting approach, and not limited to awaiting activity on file
descriptor only.  It was presented at the BSDcon late last year, and
some folks from OpenBSD and NetBSD were interested as well. 

I've often though of hacking this into Ruby to improve the threading
performance, but this hasn't been an issue for my toy applications
and hacking so far.

Anyway, it will be worth your trouble to read the paper if you're interested
or concerned about select() scalability and performance in the
presence of a large number of file descriptors.

louie