[ruby-core:108337] [Ruby master Feature#18668] Merge `io-nonblock` gems into core
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2022-04-21 09:17:18 UTC
List:
ruby-core #108337
Issue #18668 has been updated by Eregon (Benoit Daloze). I don't think the current design of io/nonblock is misleading. I would think the majority of people knowing about its existence know what it does. There is probably some bias here from people who knew about its 1.8 behavior, and that behavior was clearly broken as it would change the high-level semantics incorrectly of many other methods. So now we have the correct sensible semantics for those methods, IMHO no reason to deprecate. Also we cannot deprecate it since the Fiber scheduler needs it, as I showed above. And as @normalperson said, if one wants to use the Fiber scheduler and doesn't know the exact Ruby version, they need IO#nonblock= + IO#nonblock? to ensure the fd is O_NONBLOCK and so the Fiber scheduler is used. Or simply if they don't know the exact kind of fd or don't want to rely on the changing defaults for IO instances. https://bugs.ruby-lang.org/issues/18630 also needs io/nonblock, because that only applies to IO#nonblock? = true IO instances. And it has no effect on IO#nonblock? = false IO instances. It seems clear core devs don't want it in core. How about stdlib then? A gem is clear overkill for this, and adding non-trivial overhead for every Ruby implementation. ---------------------------------------- Feature #18668: Merge `io-nonblock` gems into core https://bugs.ruby-lang.org/issues/18668#change-97362 * 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:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>