[ruby-core:59636] Fwd: Merging nio4r into ruby-core

(Resending this as my previous attempt failed)

Hi there everyone!

For the past 2 years I have maintained a library called nio4r which
provides a cross-Ruby VM abstraction for I/O selectors which are the
underpinnings of I/O selectors and reactors:

https://github.com/celluloid/nio4r

This library supports at least MRI, JRuby, and Rubinius, and is highly
influenced by the Java NIO design.

The problem is I'm maintaining implementations for all of the popular Ruby
VMs. I think it would be better if the API were standardized into core Ruby
and each implementation could provide their own optimized implementation.

There are changes I'd like to see happen before such a standardization
occurs. However, I'd like to gauge interest about incorporating this sort
of API into the core of the Ruby language itself before that happens.

What do you all think about incorporating nio4r into Ruby itself?

--

On Tue, Jan 7, 2014 at 1:52 PM, Eric Wong <[e-mail]> wrote:

> I am mildly against this, as it would likely hinder the
> adoption/evolution of better[1] non-blocking I/O libraries
> better-suited for use with multi-threaded applications.


The advantage of nio4r over every other existing solution I am aware of is
that it's API is it is modeled after Java NIO and can therefore provide a
least common denominator API for all Ruby VMs, including JRuby. None of
them are treated as second class citizens, and all VMs can provide
optimized implementations.

It's also relatively OS agnostic, although to get good Windows support we'd
need an even leakier abstraction like libuv (which, IMO, optimizes for
Windows at the cost of all other OSes, although a more libuv-like API might
be worth considering)

There are definitely better non-blocking I/O APIs out there if you're
willing to sacrifice ubiquity. This API is intended to be something that
works fairly well everywhere.

-- 
Tony Arcieri