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!

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

nio4r is not an event framework. Instead, it’s more like a mostly
replacement for with significantly better performance and
without the arbitrary limitations. nio4r uses high performance system
like Linux’s epoll and *BSD’s kqueue which lets you monitor large
(i.e. > 1024) of Ruby IO objects with significantly less CPU usage than The main difference between nio4r and is
nio4r keeps track of IO objects you’re interested in between select
(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

Unlike, nio4r also works on JRuby, and ties into the Java NIO
subsystem. In fact, nio4r is largely modelled off of the Java NIO API.
other implementations of nio4r are provided: a C extension based on
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
on all Ruby implementations.

What is the relationship between nio4r and There isn’t a
one yet, however nio4r could be used to replace’s existing
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

Why nio4r? To a certain extent this is me wanting to scratch an itch
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
cross-Ruby implementation selector API for watching file descriptors and
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,
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

  • 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:

My Twitter: