From: "Eregon (Benoit Daloze) via ruby-core" Date: 2026-10-09T09:59:09+00:00 Subject: [ruby-core:127028] [Ruby Feature#22274] Make `IO::Buffer` no longer experimental. Issue #22274 has been updated by Eregon (Benoit Daloze). There have been new methods/classes in the last week like: `IO::Buffer#advance` https://github.com/ruby/ruby/pull/19122 `Introduce IO::Buffer::Storage and parent-relative slice views` https://github.com/ruby/ruby/pull/19186 I think these are major changes to the API and there should be a ticket here, like any other core API (whether experimental or not), for visibility and make it easy to discuss them. Like others I also feel this is too early to make IO::Buffer fully stable given such major changes. Regarding `IO::Buffer#advance` that adds extra mutable state in `IO::Buffer::Slice`s. I think that should be avoided, as then it's easy for a slice to be used incorrectly from multiple threads and cause race conditions. Even more so on Rubies with parallel threads, then 2 concurrent `advance` could only advance by 1, and adding synchronization for that would be costly and feel very strange when the rest of the IO::Buffer design doesn't keep a "relative position". I think we should not have a concept of "relative position" in IO::Buffer, it exists in Java ByteBuffer and I think overall it's a mistake and lots of unnecessary complexity. The position/index can just live outside and it's much cleaner that way. Also I think this illustrates why it's definitely not safe to share IO::Buffer between Ractors, and that freezing should actually freeze, as matz just said. Regarding the new classes there used to be a big incompatibility in the initial try but that seems resolved in that PR. @ioquatix Could you open a ticket for both of these major changes? And for future changes? Notably https://github.com/ruby/ruby/pull/19122 doesn't explain the motivation. ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274#change-119424 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- `IO::Buffer` was introduced in Ruby 3.1 by Feature #18020 as an experimental API. It provides an efficient buffer abstraction for fiber scheduler I/O, zero-copy operations, binary protocol implementations, and access from native extensions. Since then, the API has seen several Ruby releases of real-world use and substantial development. Ruby 4.1 now has cohesive semantics for buffer ownership and lifecycle, slicing, locking, string and file mappings, MemoryView integration, and single-transfer I/O operations. I propose making both the Ruby and public C interfaces of `IO::Buffer` non-experimental in Ruby 4.1. This would involve: * Removing the allocation-time experimental warning. * Removing the experimental status from the class documentation. * Removing `RB_IO_BUFFER_EXPERIMENTAL` from the public C header. * Removing warning suppression that is only required because `IO::Buffer` is experimental. * Updating NEWS to describe `IO::Buffer` as stable. `RUBY_IO_BUFFER_VERSION` would remain available for compile-time feature detection as the interface continues to evolve. Before stabilizing the interface, I would particularly appreciate feedback from JRuby and TruffleRuby maintainers. Related work: * Original proposal: https://bugs.ruby-lang.org/issues/18020 * CRuby implementation PR: https://github.com/ruby/ruby/pull/18486 * TruffleRuby implementation: https://github.com/truffleruby/truffleruby/pull/4248 * JRuby implementation: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/RubyIOBuffer.java * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/