September 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:126689] [Ruby Bug#22313] Bytecode compilation is quadratic in the size of a method due to remove_unreachable_chunk
by make_now_just (Hiroya Fujinami) 14 Sep '26

14 Sep '26

Issue #22313 has been reported by make_now_just (Hiroya Fujinami). ---------------------------------------- Bug #22313: Bytecode compilation is quadratic in the size of a method due to remove_unreachable_chunk https://bugs.ruby-lang.org/issues/22313 * Author: make_now_just (Hiroya Fujinami) * Status: Open * Assignee: make_now_just (Hiroya Fujinami) * Target version: 4.0 * ruby -v: ruby 4.0.4 (2026-05-12 revision b89eb1bcbf) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Compiling one large method whose body contains many unconditional jumps takes time quadratic in the size of the method. ## Reproduction ```ruby def build(units) src = +"def f(x)\n" units.times do |i| src << " while x < #{i}\n x = x + 1\n next if x == #{i}\n break if x > #{i}\n end\n return x if x == #{i}\n" end src << " x\nend\n" end [5_000, 10_000, 20_000].each do |units| src = build(units) t = Process.clock_gettime(Process::CLOCK_MONOTONIC) RubyVM::InstructionSequence.compile(src) printf("%6d units: %5.2f s\n", units, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t) end ``` On `ruby 4.1.0dev (2026-09-14T06:17:27Z master d973aef325) +PRISM [arm64-darwin25]` (Apple M1 Pro): ``` 5000 units: 0.25 s 10000 units: 1.08 s 20000 units: 4.38 s ``` Doubling the method's size quadruples the compile time. Ruby 4.0.4 behaves the same. ## Cause `remove_unreachable_chunk` in `compile.c` allocates a counter array sized by the method's label count and clears it on every call: ```c int *unref_counts = 0, nlabels = ISEQ_COMPILE_DATA(iseq)->label_no; if (!i) return 0; unref_counts = ALLOCA_N(int, nlabels); MEMZERO(unref_counts, int, nlabels); ``` `iseq_peephole_optimize` calls it for every unconditional jump and leave it visits, and both the number of those calls and label_no grow linearly with the method, so the MEMZERO alone costs O(jumps x labels) per method. A profile of the reproduction spends most of its compile time in `__bzero` under `iseq_peephole_optimize` -> `remove_unreachable_chunk`. As a side note, `ALLOCA_N` is also unbounded: a method with tens of thousands of labels puts hundreds of kilobytes on the C stack per call. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126687] [Ruby Feature#22312] Add parent directory operations and recursive file removal
by nobu (Nobuyoshi Nakada) 14 Sep '26

14 Sep '26

Issue #22312 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22312: Add parent directory operations and recursive file removal https://bugs.ruby-lang.org/issues/22312 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose extending `Dir.mkdir`, `Dir.rmdir`, and `File.unlink` with options for operating on directory trees. These operations currently require `FileUtils`; providing them in core would also allow recursive removal to improve robustness by using native directory descriptors or Windows handles where available. ## Proposed API ````ruby Dir.mkdir(path, permissions = 0777, perm: permissions, parents: false) Dir.rmdir(path, parents: false, ignore_non_empty: false) File.unlink(*paths, recursive: false) ```` The aliases `Dir.delete`, `Dir.unlink`, and `File.delete` receive the corresponding options. Calls without the new options retain their existing behavior. ## Creating parent directories `Dir.mkdir(path, parents: true)` creates missing parent directories and returns `0` if the target is already a directory. An existing non-directory raises an exception. ````ruby Dir.mkdir("build/cache/objects", parents: true, perm: 0700) # => 0 ```` The requested permissions apply only to the final directory. New parents use `0777`, subject to the process umask, and existing directories keep their permissions. Permissions remain ignored on Windows. ## Removing empty parent directories `Dir.rmdir(path, parents: true)` removes the target and then successive empty parents. It does not remove a filesystem root or the relative parent path `.`. Its return value remains `0`. The `ignore_non_empty:` option controls when removal stops successfully: | Value | Target directory | Parent directories | |-------------------|--------------------------------|-----------------------------------------------------| | `false` (default) | Raise if non-empty | Raise if non-empty | | `true` | Stop successfully if non-empty | Stop successfully if non-empty | | `:parents` | Require successful removal | Stop successfully if non-empty or no longer present | Other errors raise exceptions. `:parents` matches the error handling of `FileUtils.rmdir(path, parents: true)` and has no effect without `parents: true`. Removal already completed is not rolled back on an error. ````ruby Dir.rmdir("build/cache/objects", parents: true, ignore_non_empty: :parents) ```` Parent removal currently uses path-based calls to `rmdir`, resolving the path again at each step. It does not guarantee protection against concurrent renames or symbolic-link substitution in intermediate path components. Such changes can redirect removal to unintended empty directories that the process has permission to remove. Avoid using this option where another process can modify the path concurrently. Retaining descriptors for all ancestors would require a number of descriptors proportional to the path depth. Walking upward with `openat(fd, "..")` would bound descriptor usage, but could follow a directory into a different parent after a concurrent rename. The current proposal retains path-based parent removal with the limitation described above. ## Recursive removal `File.unlink(*paths, recursive: true)` also removes directories and their contents. It returns the number of supplied paths, rather than the number of entries removed. ````ruby File.unlink("build/cache", recursive: true) # => 1 ```` Symbolic links at the target, including targets specified with trailing slashes, and links inside the tree are removed without traversing their targets in the absence of concurrent replacement. Filesystem roots and paths ending in `.` or `..` are rejected. Like `FileUtils.rm_r` with its default `force: false`, this option does not suppress errors: missing paths and other failures raise exceptions, possibly after partial removal. The implementation uses descriptor-relative operations, including `openat` and `unlinkat`, on platforms supporting them. Opened directories remain accessible through their descriptors if renamed during traversal, so their contents may still be removed after a rename. Concurrent modifications can cause an exception; the operation is not atomic. Mounted filesystems inside the tree are traversed on non-Windows platforms. On Windows, the implementation retains directory handles with sharing disabled and removes entries through their handles. Reparse points in the ancestor path are rejected; reparse points at or inside the target are removed without traversal. Existing handles that conflict with exclusive access cause an error. On other platforms, a path-based fallback behaves similarly to `FileUtils.remove_entry`. It cannot prevent traversal through a symbolic link substituted concurrently for a directory, so it is unsuitable for trees another process can modify concurrently. ## Possible `force:` option An additional `force: false` keyword for `File.unlink` may be useful for cleanup operations. Combined with `recursive: true`, it could cover use cases currently served by `FileUtils.rm_rf`. This option is not implemented in the current patch. The scope of error suppression needs discussion: should `force: true` ignore only missing paths, or suppress removal errors more broadly as `FileUtils.rm_r(force: true)` does? Its applicability without `recursive: true` and the return value when some supplied paths cannot be removed also need to be defined. ## Implementation [Implementation branch](https://github.com/nobu/ruby/tree/recursive-file-operations) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126590] [Ruby Bug#22298] IO::Buffer is left unfreed with an invalid pointer when fiber scheduler raises
by hanazuki (Kasumi Hanazuki) 14 Sep '26

14 Sep '26

Issue #22298 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22298: IO::Buffer is left unfreed with an invalid pointer when fiber scheduler raises https://bugs.ruby-lang.org/issues/22298 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-06T12:40:34Z master e536482403) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When an installed Fiber scheduler raises from its I/O hook, the temporary IO::Buffer passed to the hook is left unfreed. The buffer may then outlive the memory it wraps, so accessing it afterward can cause undefined behavior. This only happens when the buffer escapes from the I/O callback, which is supposed to be a bug in the scheduler, but I think it is worth fixing silent memory corruption. ```ruby class Scheduler def block(*) = Fiber.yield def unblock(*) = nil def kernel_sleep(*) = nil def io_wait(*) = 0 def fiber_interrupt(*) = nil def fiber(&block) Fiber.new(blocking: false, &block).tap(&:transfer) end def io_write(io, buffer, offset, length) $escape = buffer # This buffer wraps a borrowed temporary memory fail end end r, w = IO.pipe Fiber.set_scheduler(Scheduler.new) Fiber.schedule { w.write('hello') } rescue nil GC.start p $escape # .inspect will read freed memory ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111789] [Ruby master Feature#19333] Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks.
by ioquatix (Samuel Williams) 14 Sep '26

14 Sep '26

Issue #19333 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #19333: Setting (Fiber Local|Thread Local|Fiber Storage) to nil should delete value in order to avoid memory leaks. https://bugs.ruby-lang.org/issues/19333 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- As it stands, Fiber Locals, Thread Locals and Fiber Storage have no way of deleting key-value associations. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 end ``` Because of this, dynamically generated associations can leak over time. This is worse for things like Threads that might be pooled (or maybe an argument against user-space pooling). In any case, having a way to delete those associations would allow application code to at least delete the associations when they no longer make sense. I propose that assigning `nil` to "locals" or "storage" should effectively delete them. e.g. ```ruby 100.times do |i| name = :"variable-#{i}" Thread.current[name] = 10 Thread.current[name] = nil # delete association end ``` A more invasive alternative would be to define new interfaces like `Thread::Local`, `Fiber::Local` and `Fiber::Storage::Local` (or something) which correctly clean up on GC. -- https://bugs.ruby-lang.org/

3 10

[ruby-core:123306] [Ruby Bug#21612] Make sure we never context switch while holding the VM lock
by luke-gru (Luke Gruber) 14 Sep '26

14 Sep '26

Issue #21612 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21612: Make sure we never context switch while holding the VM lock https://bugs.ruby-lang.org/issues/21612 * Author: luke-gru (Luke Gruber) * Status: Open * Target version: 3.5 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## The Problem We're seeing errors in our application that uses ractors. The errors look like: ``` [BUG] unexpected situation - recordd:1 current:0 error.c:1097 rb_bug_without_die_internal vm_sync.c:275 disallow_reentry eval_intern.h:136 rb_ec_vm_lock_rec_check eval_intern.h:147 rb_ec_tag_state vm.c:2619 rb_vm_exec vm.c:1702 rb_yield eval.c:1173 rb_ensure ``` We concluded that there was context switching going on while a thread held the VM lock. During the investigation into the issue, we added assertions in the code that we never yield to another thread with the VM lock held. We enabled these VM lock assertions even in single ractor mode. These assertions were failing in a few places, but most notably in finalizers. Finalizers are running with the VM lock held, and they were context switching and causing this issue. ## Why Is This Bad? There are a few reasons we shouldn't be able to context switch while holding the VM lock. In single-ractor mode with threads A and B: 1) Anything in this critical section should be thought of as a transaction related to the memory that's changed inside. if A has the lock, manipulates some global memory and yields to B with the lock still taken and without finishing the memory updates and then B takes it and starts writing to the same memory, the state of this global memory could be corrupted. Currently we don't actually take the VM lock in single-ractor mode, but that doesn't mean these issues can't happen. Yielding to another thread in the middle of manipulating global memory *can* still happen and it causes similar issues. In multi-ractor mode with ractors A and B: 1) We get the same issues as in single-ractor mode. 2) We can also get deadlocks if A has the lock, yields to B and B is blocked waiting on the lock. Unfortunately, many things can cause context switching in Ruby, so what is safe to call when the VM lock is taken? ## Guidelines I've come up with some guidelines. With the VM lock held, You should be able to: * Create ruby objects, call `ruby_xmalloc`, etc. * Jump using `EC_JUMP_TAG`. The lock will automatically be unlocked depending on how far up the call stack you locked it and where you're jumping to. * Check ruby interrupts. Since jumping can pop ruby frames and popping frames checks interrupts, you are allowed. It should never context switch with the VM lock held, even if the ruby thread's quantum is up. You shouldn't be able to: * Call any ruby method or enter Ruby's VM loop. For example, `rb_funcall` is not allowed, nor is `rb_warn` (it can call ruby code). `rb_sprintf` is not allowed because it can call `rb_inspect`. * Call `rb_nogvl` * Enter any blocking operation managed by Ruby. * Call a ruby-level mechanism that can context switch, like `rb_mutex_lock`. ## The Fix Of course, unlocking during finalizers is the main fix but there are other places that also need unlocking. I think adding assertions that the VM lock is not held will be important in finding these bugs and not creating regressions in the future. We don't have to add lots of these, just in a few places. These assertions, which only run in debug mode, should also run when in single-ractor mode. ## Future Work I think some documentation would be helpful for what is and isn't allowed while holding the VM lock and other locks in the cruby source. I am currently working on a `Concurrency Guide` for cruby developers that includes this info. It will not go over every lock, just the VM lock and the "all other locks" category. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116041] [Ruby master Bug#20155] Using value of rb_fiber_scheduler_current() crashes Ruby
by paddor (Patrik Wenger) 14 Sep '26

14 Sep '26

Issue #20155 has been reported by paddor (Patrik Wenger). ---------------------------------------- Bug #20155: Using value of rb_fiber_scheduler_current() crashes Ruby https://bugs.ruby-lang.org/issues/20155 * Author: paddor (Patrik Wenger) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- While trying to manually block/unblock fibers from an extension using the Fiber Scheduler, I noticed that using the return value of `rb_fiber_scheduler_current()` crashes Ruby. I've created a minimal extension gem called "fiber_blocker". Its test suite shows the behavior. See https://github.com/paddor/fiber_blocker, especially the lines containing `FIXME`. Passing `Fiber.scheduler` to the extension functions works. But letting it get the current scheduler itself does not seem to work. Is `rb_fiber_scheduler_current()` not the equivalent to `Fiber.scheduler`? Even just printing the its return value with `#p` will crash Ruby. Ruby either crashes like this: ``` # Running: T1 BEGIN T2 BEGIN T1 END ..T1 BEGIN ext: blocking fiber passed scheduler = #<Scheduler:0x00007fc5f22d39e8 @readable={}, @writable={}, @waiting={}, @closed=false, @lock=#<Thread::Mutex:0x00007fc5f22ec8d0>, @blocking={}, @ready=[], @urgent=[#<IO:fd 5>, #<IO:fd 6>]> T2 BEGIN ext: unblocking fiber T1 END .E Finished in 1.007014s, 3.9721 runs/s, 2.9791 assertions/s. 1) Error: TestFiberBlocker#test_fiber_blocker_current_fiber: fatal: machine stack overflow in critical region No backtrace ``` Or with a segfault: ``` # Running: FiberBlocker.test works. .T1 BEGIN T2 BEGIN T1 END .T1 BEGIN ext: blocking fiber /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40: [BUG] Segmentation fault at 0x00000000390d8f98 ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:---- s:0012 e:000011 CFUNC :block_fiber c:0002 p:0014 s:0006 e:000005 BLOCK /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block in test_fiber_blocking_in_ext' /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/test/test_fiber_blocker.rb:40:in `block_fiber' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 4 -- Machine register context ------------------------------------------------ RIP: 0x00007f1554f17ad8 RBP: 0x00000000390d8f90 RSP: 0x00007f153a79e280 RAX: 0x00007f1554addba8 RBX: 0x00007f153a79eab0 RCX: 0x0000000000000000 RDX: 0x00007f1554ade600 RDI: 0x00007f15551e8788 RSI: 0x0000000000000ae1 R8: 0x000000000000002b R9: 0x00007f153a79f038 R10: 0x00007f1554c0b9b0 R11: 0x00007f153a79e490 R12: 0x0000000000000ae1 R13: 0x0000000000000000 R14: 0x0000000000000000 R15: 0x000055ab732d7df0 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_print_backtrace+0x14) [0x7f1554f24961] /home/user/src/ruby-3.3.0/vm_dump.c:820 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_bugreport) /home/user/src/ruby-3.3.0/vm_dump.c:1151 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0x104) [0x7f1554d1c214] /home/user/src/ruby-3.3.0/error.c:1065 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(sigsegv+0x4f) [0x7f1554e700df] /home/user/src/ruby-3.3.0/signal.c:926 /lib/x86_64-linux-gnu/libc.so.6(0x7f1554842520) [0x7f1554842520] /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_CLASS+0x0) [0x7f1554f17ad8] ./include/ruby/internal/globals.h:178 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(gccct_method_search) /home/user/src/ruby-3.3.0/vm_eval.c:475 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv_scope) /home/user/src/ruby-3.3.0/vm_eval.c:1063 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_funcallv) /home/user/src/ruby-3.3.0/vm_eval.c:1084 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_inspect+0x19) [0x7f1554dc1569] /home/user/src/ruby-3.3.0/object.c:697 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby__sfvextra+0x11a) [0x7f1554e7223a] /home/user/src/ruby-3.3.0/sprintf.c:1119 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(BSD_vfprintf+0xa69) [0x7f1554e73059] /home/user/src/ruby-3.3.0/vsnprintf.c:830 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(RBASIC_SET_CLASS_RAW+0x0) [0x7f1554e75b56] /home/user/src/ruby-3.3.0/sprintf.c:1168 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(ruby_vsprintf0) /home/user/src/ruby-3.3.0/sprintf.c:1169 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_enc_vsprintf+0x5d) [0x7f1554e75ecd] /home/user/src/ruby-3.3.0/sprintf.c:1195 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_sprintf+0x9d) [0x7f1554e7607d] /home/user/src/ruby-3.3.0/sprintf.c:1225 /home/user/dev/oss/async_ruby_test/rbnng/fiber_blocker/lib/fiber_blocker/fiber_blocker.so(block_fiber+0x4a) [0x7f1554ad430a] ../../../../ext/fiber_blocker/fiber_blocker.c:29 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_cfp_consistent_p+0x0) [0x7f1554ef64b4] /home/user/src/ruby-3.3.0/vm_insnhelper.c:3490 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame_) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3492 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_with_frame) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3518 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_call_cfunc_other) /home/user/src/ruby-3.3.0/vm_insnhelper.c:3544 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_sendish+0x9e) [0x7f1554f06f87] /home/user/src/ruby-3.3.0/vm_insnhelper.c:5581 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(vm_exec_core) /home/user/src/ruby-3.3.0/insns.def:834 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_exec+0x19a) [0x7f1554f0d1fa] /home/user/src/ruby-3.3.0/vm.c:2486 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_vm_invoke_proc+0x5f) [0x7f1554f12e0f] /home/user/src/ruby-3.3.0/vm.c:1728 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_fiber_start+0x1ba) [0x7f1554cf098a] /home/user/src/ruby-3.3.0/cont.c:2536 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(fiber_entry+0x20) [0x7f1554cf0d00] /home/user/src/ruby-3.3.0/cont.c:847 /home/user/.rubies/ruby-3.3.0/lib/libruby.so.3.3(rb_threadptr_root_fiber_setup) (null):0 ``` I hope I'm not missing something obvious. My C isn't very good. -- https://bugs.ruby-lang.org/

2 12

[ruby-core:126679] [Ruby Feature#19023] Enable riscv64 coroutines on riscv64-freebsd, arm32 on arm*-freebsd and ppc on powerpc-freebsd
by ioquatix (Samuel Williams) 14 Sep '26

14 Sep '26

Issue #19023 has been updated by ioquatix (Samuel Williams). Status changed from Open to Closed Fixed in <https://github.com/ruby/ruby/commit/066814022dcdaa361a06bb441ce30b11d4be0280>. ---------------------------------------- Feature #19023: Enable riscv64 coroutines on riscv64-freebsd, arm32 on arm*-freebsd and ppc on powerpc-freebsd https://bugs.ruby-lang.org/issues/19023#change-118974 * Author: pkubaj (Piotr Kubaj) * Status: Closed ---------------------------------------- Enable riscv64 coroutines on riscv64-freebsd, arm32 on arm*-freebsd and ppc on powerpc-freebsd https://github.com/ruby/ruby/pull/5852 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126531] [Ruby Feature#22274] Make `IO::Buffer` no longer experimental.
by ioquatix (Samuel Williams) 13 Sep '26

13 Sep '26

Issue #22274 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274 * 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/Rub… * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124711] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching
by synacker (Mikhail Milovidov) 12 Sep '26

12 Sep '26

Issue #21869 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21869: Add receive_all Method to Ractor API for Message Batching https://bugs.ruby-lang.org/issues/21869 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** The Ractor API provides an excellent mechanism for inter‑thread communication, but it currently lacks a built‑in message batching technique. I propose adding a receive_all method to enable batch processing of messages, which can significantly improve performance in high‑load scenarios. **Motivation** In distributed queued systems, processing messages one‑by‑one (as with the current receive method) can introduce unnecessary overhead. Batch processing allows: Reduced context‑switching overhead. More efficient I/O operations (e.g., fewer file writes). Better throughput in high‑concurrency environments. **Proposed Solution** Add a receive_all method to the Ractor API that: Returns all available messages in the Ractor’s mailbox at once (as an array). **Demonstration Code** Below is a benchmark comparing individual receive vs. batch receive_all: ``` ruby require 'benchmark' class RactorsTest def initialize(count) @count = count @ractor1 = Ractor.new(count, 'output1.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? message = receive file.write("Ractor 1 received message: #{message}\n") file.flush count -= 1 end end end @ractor2 = Ractor.new(count, 'output2.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? messages = receive_all messages.each do |message| file.write("Ractor 2 received message: #{message}\n") end count -= messages.length file.flush end end end end def run1 @count.times do |i| @ractor1.send("Message #{i + 1}") end @ractor1.join end def run2 @count.times do |i| @ractor2.send("Message #{i + 1}") end @ractor2.join end end records = 1_000_000 test = RactorsTest.new(records) p [:once, Benchmark.realtime { test.run1 }.round(2)] p [:all, Benchmark.realtime { test.run2 }.round(2)] ``` **Benchmark Results** On my system, receive_all shows ~4x improvement over individual receive: **Key Observations:** Ractor1 (using receive): Processes each message individually, resulting in frequent I/O calls. Ractor2 (using receive_all): Processes all queued messages at once, minimizing I/O overhead -- https://bugs.ruby-lang.org/

4 12

[ruby-core:126672] [Ruby Bug#18661] Net::HTTP behavior changed between 2.6 and 3.1 on windows.
by hsbt (Hiroshi SHIBATA) 12 Sep '26

12 Sep '26

Issue #18661 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed Fixed on master by https://github.com/ruby/ruby/pull/18611. The hang is not inside `connect_nonblock`. Winsock reports a failed non-blocking `connect(2)` only through the exceptfds of `select(2)`, and `IO#wait_writable` never asks for that set, so `Addrinfo#connect_internal` kept waiting on a connection that had already been refused and burned the whole timeout. On Windows `Socket.tcp("127.0.0.1", <closed port>, connect_timeout: 5)` raised `Errno::ETIMEDOUT` after 5.01 seconds and now raises `Errno::ECONNREFUSED` after 2.06 seconds, which is Winsock's own latency before it reports the reset. `SO_ERROR` also carried a raw WinSock error code instead of an errno, so the failure surfaced as a bare `SystemCallError`. That is fixed as well. I could not reproduce the Rails system test end to end, so please reopen if it still hangs when you try it after the 4.1.0 release. ---------------------------------------- Bug #18661: Net::HTTP behavior changed between 2.6 and 3.1 on windows. https://bugs.ruby-lang.org/issues/18661#change-118969 * Author: jleblanc (Joshua LeBlanc) * Status: Closed * Assignee: windows * ruby -v: ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [x64-mingw-ucrt] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- We are upgrading a rails application from Ruby 2.6 to Ruby 3.1 on Windows. Running rails systems tests hang on Ruby 3.1, while they succeed on Ruby 2.6. I tracked this down to Ruby 3.1's Net::HTTP using Socket.tcp rather than the old TCPSocket. Specifically, in `socket.rb`, `connect_internal` calls `connect_nonblock(self, exception: false)`, which ultimately hangs until timing out on windows. Modifying the `socket.rb` source to use `connect(self)` instead results in a successful operation. To be clear, the hanging operation is `socket.rb#connect_nonblock`, which is on line 1214 Reproduction: 1. Install Ruby 3.1 on Windows - I used RubyInstaller: https://github.com/oneclick/rubyinstaller2/releases/download/RubyInstaller-… 2. Clone the reproduction project: https://github.com/joshleblanc/windows_net_http_problem 3. Run `bundle install` 4. Run `rails test:system` Chrome will open, however a connection will never be made, ultimately timing out. To test this same process in earlier versions of ruby, simply create a new rails project with `rails new -O -J -S <name>`, add the `ffi` and `tzinfo-data` gems to the gemfile, and scaffold a new resource. Running `rails test:system` from this point should succeed. -- https://bugs.ruby-lang.org/

1 0