Merging nio4r into ruby-core

[Tony Arcieri]

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?

--
Tony Arcieri

[Eric Wong]

(I am not sure how many of the lists you sent to allow cross-posting,
I have not seen this on ruby-core, yet, and I'm not on dev@jruby).

Tony Arcieri <bas...@gmail.com> wrote:
> 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?

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.


[1] Mainly, exposing one-shot notifications (via EV_ONESHOT and
EPOLL_ONESHOT in kqueue and epoll respectively) to make
multi-threaded programming much easier and safer
(without needing userspace locks, even!).