[ANN] nio4r 0.1.0: New IO for Ruby (Initial Christmas release!)

Merry Christmas everyone! In the spirit of Matz's tradition of Christmas
releases I'm releasing a gem today: New IO for Ruby!

https://github.com/tarcieri/nio4r
http://rubygems.org/gems/nio4r

Around Christmastime some 4 years ago, I started working on a library
called Rev which I would later rename to Cool.io, an event framework for
Ruby. Unfortunately Cool.io largely lingered in obscurity. Fast-forward to
today, and I'm not so sure about "event frameworks" in general. I'd like to
go in a different direction. It's another Christmas and I'm releasing
another I/O gem :)

nio4r is not an event framework. Instead, it's more like a mostly drop-in
replacement for Kernel.select with significantly better performance and
without the arbitrary limitations. nio4r uses high performance system calls
like Linux's epoll and *BSD's kqueue which lets you monitor large numbers
(i.e. > 1024) of Ruby IO objects with significantly less CPU usage than
Kernel.select. The main difference between nio4r and Kernel.select is that
nio4r keeps track of IO objects you're interested in between select calls
(keeping the state in the kernel itself as possible). This lets you not
only monitor significantly more objects, but eliminates the costly setup
associated with building the interest sets for Kernel.select.

Unlike Cool.io, nio4r also works on JRuby, and ties into the Java NIO
subsystem. In fact, nio4r is largely modelled off of the Java NIO API. Two
other implementations of nio4r are provided: a C extension based on libev,
and a pure Ruby version for those Rubies that don't support the MRI C
extension API. nio4r's goal is to provide as good as possible performance
on all Ruby implementations.

What is the relationship between nio4r and Cool.io? There isn't a specific
one yet, however nio4r could be used to replace Cool.io's existing native
extension, and in doing so would provide a path to JRuby support. If
someone was feeling particularly adventurous, they could potentially
rewrite EventMachine with nio4r instead of the buggy, crufty, largely
unmaintained byzantine 10,000 line C++ native extension EventMachine ships
today.

--

Why nio4r? To a certain extent this is me wanting to scratch an itch I've
had for quite some time: providing a way to write evented code without a
large framework as a dependency. nio4r's primary goal is a high-performance
cross-Ruby implementation selector API for watching file descriptors and is
not intended to be an alternative to other Ruby IO enhancement projects
like Kinder Gentler IO (KGIO) which has mostly orthogonal goals.

My intended use case is bolstering the fledgling IO subsystem in my
concurrency library Celluloid. With nio4r as its underpinnings, Celluloid
should provide a great way to blend threaded and evented concepts. Every
Celluloid actor can function as a simplified "EventMachine", and as
Celluloid already wraps all events in fibers instead of exposing
callback-driven APIs, it should feel as simple and natural as using threads
+ blocking IO with significantly better performance.

My real hope is that Ruby implementers can help shape nio4r, ironing out
the kinks, then providing their own platform-native implementations that
can leverage better internal integration for more performance. Perhaps
nio4r could even be a standard API in Ruby 2.0.

More information on Celluloid:
https://github.com/tarcieri/celluloid

My Twitter:
http://twitter.com/bascule

-- 
Tony Arcieri