[ruby-core:108137] [Ruby master Feature#18668] Merge `io-nonblock` gems into core

Issue #18668 has been updated by Eregon (Benoit Daloze).


Sorry, it seems Redmine/I messed up the link by including the `:` in it.
This should work: https://github.com/search?q=require+io%2Fnonblock&type=Code
So that's ~40000 usages of `require io/nonblock' as far as I can see.
GitHub search isn't great though, so there is likely a lot of duplicate results (due vendored code, etc), and no easy way to search for method calls specifically.

This (or variants) might be more helpful, it uses the new GitHub search: https://cs.github.com/?scopeName=All+repos&scope=&q=.nonblock%3F+language%3ARuby

> OK I can understand it’s handy for debugging purposes. That, however, sounds more like it’s not the feature needed for everyone.

I agree it's not needed by everyone. OTOH that can be said for so many methods in core.

IMHO, these 3 methods belong to IO core, implementation-wise and API-wise (ways to set it but not query it, annoying for debugging).
They might not be used a lot, but I don't think this is so important for core, there are plenty of methods in core not used much (e.g., most of `Process` methods).
I think stability and good naming are more important for core, and those methods are good at that.

> We want smaller core because of vulnerabilities. A separate gem can have a separate CVE, separate release, and administrators can avoid replacing everything only because a tiny fraction of our code has some issue. This is better than having security releases every time.

Yes, but these 3 methods are clearly insignificant for vulnerabilities. Is that not obvious?
https://github.com/ruby/io-nonblock/blob/e20578b24405d225e6383d6c5ebfb7ffefac646b/ext/io/nonblock/nonblock.c is 97 SLOC of C code, if it was written in Ruby it'd probably be just 10 lines (e.g., using `IO#fcntl`).
It's tiny, it's extremely unlikely to have vulnerabilities, and it's never had a vulnerability in 10+ years AFAIK.
In fact, the vast majority of code in that repo (1257 SLOC according to `cloc .`) is all boilerplate that wouldn't be there if this was in core.

And if those methods were written in Ruby (e.g., using `IO#fcntl`), it'd probably be impossible to have a vulnerability in these 3 methods, so maybe that's a good reason to rewrite them using Ruby code.

So I understand the separate security release argument, but it seems clear there is a limit at which it's not worth the overhead, and io-nonblock seems way below that limit (in term of size and likeliness of vulnerabilities).
(joke: otherwise let's make a gem for every core method?)

----------------------------------------
Feature #18668: Merge `io-nonblock` gems into core
https://bugs.ruby-lang.org/issues/18668#change-97113

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
----------------------------------------
The new io-nonblock gem defines just 3 methods on IO: (https://github.com/ruby/io-nonblock/blob/e20578b24405d225e6383d6c5ebfb7ffefac646b/ext/io/nonblock/nonblock.c#L137-L139)
* IO#nonblock?
* IO#nonblock=(nonblock)
* IO#nonblock(nonblock = true, &block)

I think these 3 methods should move to core, and the gem become a noop if these methods are already defined in core.
These methods are small and yet they access IO internals and their behavior is extremely unlikely to change.
Their behavior and names are well known and established.

The benefit of a gem seems nonexistent here (no point to version those 3 methods), while the cost is significant (have to support each Ruby implementation, while this code just makes more sense in each Ruby implementation's repo).

io/nonblock is useful to tell if an IO is in non-blocking mode and to set it upfront.
This is needed when using a Fiber scheduler but also other cases such as https://bugs.ruby-lang.org/issues/18630#note-9.

In fact `io/nonblock` is so small it's already core in TruffleRuby.
Many core IO methods even need to check/set whether an IO is nonblocking, so it's natural to just use the existing methods for that when such IO methods are written in Ruby.

No gem seems to depend on io-nonblock anyway, so it seems of no use to be a gem, and it should either be core or stdlib-not-a-gem:
https://github.com/ruby/io-nonblock/network/dependents
https://rubygems.org/gems/io-wait/reverse_dependencies

Proposal:

* Merge io-nonblock into io.c for Ruby 3.2
* Publish a new io-nonblock version that simply noops if the methods are already defined, or an empty gem (so the stdlib io/nonblock gets used).
* Add a lib/io/nonblock.rb stub for compatibility, with eventually a deprecation warning.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>