From: "Eregon (Benoit Daloze)" Date: 2022-04-20T10:48:24+00:00 Subject: [ruby-core:108316] [Ruby master Feature#18668] Merge `io-nonblock` gems into core Issue #18668 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-11: > Okay, can you show a self-contained program that demonstrates it? ```ruby require 'io/nonblock' class Scheduler def block raise end def unblock raise end def kernel_sleep raise end def io_wait(*) raise "io_wait called (expected)" end def fiber(&block) Fiber.new(&block).resume end end Fiber.set_scheduler Scheduler.new $stdin.nonblock = true # needed to use scheduler for this IO Fiber.schedule do print "> " p $stdin.gets end ``` > Is there another situation than a Fiber scheduler where IO#nonblock= is important? Maybe not for `IO#nonblock=`. I think `IO#nonblock?` is useful for several cases, and notably to find out if a fd is nonblocking, which e.g., matters when it's passed to a C extension. So it's an helpful method for debugging. > I think we may set O_NONBLOCK to all file descriptors by default. IIRC there were issues with that, notably when @normalperson tried it a while ago. @ioquatix might know more. stdstreams/File seem nonblock?=false currently, and socket/pipe seem nonblock?=true currently. Also, maybe O_NONBLOCK by default is actually slower for IO (without a Fiber scheduler)? It will typically cause more syscalls, isn't it? > There is circumstantial evidence that this flag is not important to the interpreter itself (except a Fiber scheduler): when`IO#read_nonblock` is called, O_NONBLOCK is implicitly set, and never reset. Yes, it does not matter for most methods, hence I don't see why it's a "problem" to include it into core. AFAIK Ruby developers see stdlib/default gems as "code shipped with Ruby and should work well", and so have no reason to think that because `IO#nonblock*` is behind `require 'io/nonblock'` it should not be used. My opinion is there is no problem if people use `IO#nonblock*`. And there is also no problem if it is not used often (the case for many other core methods). ---------------------------------------- Feature #18668: Merge `io-nonblock` gems into core https://bugs.ruby-lang.org/issues/18668#change-97337 * 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: