From: Tony Arcieri <bascule@...>
Date: 2014-01-07T17:06:38-08:00
Subject: [ruby-core:59636] Fwd: Merging nio4r into ruby-core

--001a11c2501213f4bf04ef6b1cbe
Content-Type: text/plain; charset=ISO-8859-1

(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 <normalperson@yhbt.net> 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

--001a11c2501213f4bf04ef6b1cbe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote">(Resending this as my previous =
attempt failed)<br><br><div dir=3D"ltr">Hi there everyone!<div><br></div><d=
iv>For the past 2 years I have maintained a library called nio4r which prov=
ides a cross-Ruby VM abstraction for I/O selectors which are the underpinni=
ngs of I/O selectors and reactors:</div>



<div><br></div><div><a href=3D"https://github.com/celluloid/nio4r" target=
=3D"_blank">https://github.com/celluloid/nio4r</a></div><div><br></div><div=
>This library supports at least MRI, JRuby, and Rubinius, and is highly inf=
luenced by the Java NIO design.</div>



<div><br></div><div>The problem is I&#39;m maintaining implementations for =
all of the popular Ruby VMs. I think it would be better if the API were sta=
ndardized into core Ruby and each implementation could provide their own op=
timized implementation.</div>



<div><br></div><div>There are changes I&#39;d like to see happen before suc=
h a standardization occurs. However, I&#39;d like to gauge interest about i=
ncorporating this sort of API into the core of the Ruby language itself bef=
ore that happens.</div>



<div><br></div><div>What do you all think about incorporating nio4r into Ru=
by itself?</div><div><br></div><div>--</div></div></div><div><br></div>On T=
ue, Jan 7, 2014 at 1:52 PM, Eric Wong=A0<span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:normalperson@yhbt.net" target=3D"_blank">normalperson@yhbt.net</a>&gt;=
</span>=A0wrote:<div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">I am mildly against this, as it would likely hinder the<br>

</span><span style=3D"font-family:arial,sans-serif;font-size:13px">adoption=
/evolution of better[1] non-blocking I/O libraries<br></span><span style=3D=
"font-family:arial,sans-serif;font-size:13px">better-suited for use with mu=
lti-threaded applications.</span></blockquote>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">The=
 advantage of nio4r over every other existing solution I am aware of is tha=
t it&#39;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 the=
m are treated as second class citizens, and all VMs can provide optimized i=
mplementations.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">It&=
#39;s also relatively OS agnostic, although to get good Windows support we&=
#39;d need an even leakier abstraction like libuv (which, IMO, optimizes fo=
r Windows at the cost of all other OSes, although a more libuv-like API mig=
ht be worth considering)</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">The=
re are definitely better non-blocking I/O APIs out there if you&#39;re will=
ing to sacrifice ubiquity. This API is intended to be something that works =
fairly well everywhere.</span></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div>-- <br>Tony Arcieri<br>
</div></div>

--001a11c2501213f4bf04ef6b1cbe--