[ANN] nio4r 2.0.0: cross-platform asynchronous I/O primitives for Ruby

[Tony Arcieri]

nio4r is a set of low-level asynchronous I/O primitives with multiple cross-platform native code backends including a C extension based on libev, a java.nio backend for JRuby, and a pure Ruby version based on Kernel.select:

https://github.com/socketry/nio4r

ActionCable, a web socket framework included with Rails 5, uses nio4r for monitoring multiple WebSockets for I/O readiness.

--

nio4r 2.0.0 primarily includes new features and bugfixes, with few breaking changes. The primary reason for bumping the major version is dropping support for all Ruby versions prior to 2.2.2.

The main new feature announcement is NIO::ByteBuffer: a StringIO-like type backed by native code implementations which can be used for high-performance non-blocking I/O. The implementation was contributed to nio4r as a Google Summer of Code project by Upekshe Jayasekera:

https://github.com/socketry/nio4r/wiki/Byte-Buffers

nio4r is now located under the GitHub "socketry" project. Expect more socketry-related announcements soon!

Full change log:

• #53 Limit lock scope to prevent recursive locking. (@johnnyt)

• #95 NIO::ByteBuffer Google Summer of Code project. (@UpeksheJay, @tarcieri)

• #111 NIO::Selector#backend introspection support. (@tarcieri)

• #112 Upgrade to libev 4.23. (@tarcieri)

• #119 Disambiguate wakeup vs timeout (fixes #63, #66). (@tarcieri)

• #124 Monitor interests API improvements. (@tarcieri)

• Drop Ruby 2.0 and 2.1 support, require Ruby 2.2.2+. (@tarcieri)

--

Tony Arcieri

[Tony Arcieri]

On Thu, Dec 29, 2016 at 7:01 AM, Tiago Cardoso <honeyry...@gmail.com> wrote:

* Are bytebuffers to be integrated in celluloid-io?

I've been planning on doing another release of Celluloid soon. I might look at doing integration work then.

 

They certainly seem to be a candidate, specially the tcp socket buffer operations, but since nio4r moved organization, and celluloid-io being in maintenance mode/not receiving contributions at all for quite some time, this might be unclear. 

Right now I've been playing with making an async/await framework for Ruby which is much simpler than Celluloid::IO. But yes, Celluloid::IO is a candidate for such buffers.

 

* I've checked the signatures for read_from and write_to from io's,and one can't set read/write timeouts.

read_from / write_to are non-blocking, so timeouts are irrelevant.

--

Tony Arcieri

[Tiago Cardoso]

I think timeouts are relevant, even in a non-blocking scenario. This was one thing that seemed well-designed in http/socketry, and celluloid-io/nio4r could definitely take advantage of. 

I think you mean that, in a non-blocking scenario, read/write from/to slow client/server is not going to hurt concurrent connections, but in a scenario where, i.e., you allow 1024 connections, and a malicious actor reads/writes a few bytes and then stops interaction while keeping the socket open, at some point your handlers will block the server because it will wait indefinitely. IMO this is what the go http server gets right. 

I think this could be a use-case to take into consideration, although nio4r doesn't seem to have built-in support for wait timeouts (timers gem maybe?). 

[Tony Arcieri]

On Fri, Dec 30, 2016 at 4:22 AM, Tiago Cardoso <honeyry...@gmail.com> wrote:

I think you mean that, in a non-blocking scenario, read/write from/to slow client/server is not going to hurt concurrent connections

No, I meant the newly added NIO::ByteBuffer#read_from/write_to methods never block and always return immediately, therefore there's nothing to time out. It's more or less as if they have a built-in timeout of 0.

nio4r doesn't seem to have built-in support for wait timeouts

The only timeout support in nio4r is in the selector API. It's designed to be a set of least common denominator primitives with the thinnest possible wrappers to native APIs.

(timers gem maybe?).

Yes, use the timers gem for that.

--

Tony Arcieri