Tony Arcieri
2014-01-07 19:21:53 UTC
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?
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
Tony Arcieri