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

[ruby-core:124851] [Ruby Bug#21918] fiber scheduler: fiber interrupt triggers for IOs that haven't been closed
by chucke (Tiago Cardoso) 12 Sep '26

12 Sep '26

Issue #21918 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21918: fiber scheduler: fiber interrupt triggers for IOs that haven't been closed https://bugs.ruby-lang.org/issues/21918 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've been chasing an issue, which I believe is to with the recent introduction of the `fiber_interrupt` hook in ruby 4. As a reproduction I have the following snippet: ```ruby require "socket" require_relative "test/fiber/scheduler" # use the one defined here: https://github.com/ruby/ruby/blob/master/test/fiber/scheduler.rb udp = UDPSocket.new(Socket::AF_INET) tcp = Socket.new(Socket::AF_INET, :STREAM, 0) tcp.connect(Socket.sockaddr_in(80, "nghttp2")) t = Thread.start do Thread.current.abort_on_exception = true scheduler = Scheduler.new Fiber.set_scheduler scheduler 5.times do Fiber.schedule do begin puts "#{Fiber.current.object_id} -> wait udp" udp.to_io.wait_readable(2) rescue IOError => e puts "#{Fiber.current.object_id} -> udp io error: #{e}" end begin puts "#{Fiber.current.object_id} -> closing udp" udp.close puts "#{Fiber.current.object_id} -> closed udp" puts "#{Fiber.current.object_id} -> wait tcp" tcp.to_io.wait_readable(2) puts "#{Fiber.current.object_id} -> done" rescue => e puts "#{Fiber.current.object_id} -> tcp io error: #{e}" else puts "#{Fiber.current.object_id} -> closing tcp" tcp.close end end end end t.join ``` This produces the following output to me: ``` 1472 -> wait udp 1488 -> wait udp 1496 -> wait udp 1504 -> wait udp 1512 -> wait udp 1472 -> closing udp 1488 -> closing udp 1488 -> closed udp 1488 -> wait tcp 1496 -> closing udp 1496 -> closed udp 1496 -> wait tcp 1504 -> closing udp 1504 -> closed udp 1504 -> wait tcp 1512 -> closing udp 1512 -> closed udp 1512 -> wait tcp 1512 -> tcp io error: stream closed in another thread 1504 -> tcp io error: stream closed in another thread 1496 -> tcp io error: stream closed in another thread 1488 -> tcp io error: stream closed in another thread 1472 -> closed udp 1472 -> wait tcp 1472 -> done 1472 -> closing tcp ``` The thing that makes this program very confusing is that the "stream closed in another thread" related to the udp socket is raised while waiting for read readiness on the tcp socket. In such a situation, I'd expect the error to relate to the actual socket being waited on, not something else that fiber does not care about anymore. One thing that could have helped would be to have the reference of which IO object the exception relates to in the exception (aka `IOError#io` would return the socket). Nevertheless, I'd still consider an issue that this triggers in the wrong "fiber.yield" moment. Therefore, I think there are two possible outcomes here: 1. all fibers stop on `udp.close` until it is in fact closed (and then IOError is raised before the "closed udp" message can be printed) 2. exceptions related to IOs not actively being monitored by the current fiber are ignored. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126393] [Ruby Feature#22245] Reduce Array#& cost when self is much shorter than the argument
by andrey.samsonov＠gmail.com (Andrey Samsonov) 11 Sep '26

11 Sep '26

Issue #22245 has been reported by andrey.samsonov(a)gmail.com (Andrey Samsonov). ---------------------------------------- Feature #22245: Reduce Array#& cost when self is much shorter than the argument https://bugs.ruby-lang.org/issues/22245 * Author: andrey.samsonov(a)gmail.com (Andrey Samsonov) * Status: Open ---------------------------------------- # Abstract For intersections of larger arrays, Ruby builds a temporary hash from the argument to `Array#&`. As a result, `short & long` can be slower and use much more temporary memory than `long & short`. Callers cannot always choose the cheaper order because `Array#&` preserves the objects and order of `self`. This proposal reduces that operand-order cost when `self` is much shorter, making performance less dependent on which result order the caller needs. In a local test, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. Benchmarks modeled on real call sites improved by about 1.7-2.7x. An unmodified Rails 8.1 Active Model benchmark improved by about 1.3x. `Array#intersection` uses the same C function and gets the same change. # Background When either array has more than 16 elements, Ruby uses a hash-based lookup and always builds the temporary hash from the argument. This creates a large cost difference between: ```ruby short & long long & short ``` The first expression hashes `long`. The second hashes `short`, but it can return elements in a different order. Some callers need the first expression because of that order. [Feature #17109] proposed removing the same operand-order cost by swapping the arrays. It was rejected because that changed the documented result order. This proposal instead preserves the objects and order from `self`. This proposal hashes `self` when it is at most half as long as the argument. It then scans the argument and returns matches in `self` order. For normal `#hash` and `#eql?` implementations, the result contains the same objects from `self`, in the same order, without duplicates. # Proposal ## Compatibility question May `Array#&` and `Array#intersection` choose which array to hash based on their lengths? The result stays the same for built-in values and custom equality methods where `#eql?` is an equivalence relation, equal elements have equal `#hash` values, and both methods are stable, have no side effects, and return normally. For stable, side-effect-free methods, both hash-based paths make the same number of `#hash` calls. The receiver, order, and number of `#eql?` calls can change. Mutation or exceptions can also change how many calls complete. The patch makes the RDoc direction-neutral. `Array#intersect?` has chosen the hash side by length since Ruby 3.1. This is relevant precedent, although `intersect?` returns only a boolean. This patch also preserves the objects and order from `self`. ## Implementation When `len(self) <= len(argument) / 2`, and the arrays use the hash-based path: 1. Build a hash from the distinct elements of `self`. 2. Keep their first positions in `self`. 3. Scan the argument and mark each match. 4. Return the marked elements in `self` order. Small arrays, near-equal arrays, and a long `self` with a short argument keep the current path. `Array#|` is not changed because its operand-order cost has a different cause. `Array#-` preserves repeated unmatched elements and needs a separate algorithm and compatibility analysis. ## Why start at 2x? The 2x threshold is an empirical starting point, not part of the API. Forced-threshold benchmarks gave mixed results below 2x. At 2x, all tested cases with distinct argument elements improved, with median gains of about 1.1-1.3x. I would welcome maintainer guidance on whether Ruby has an established method or relevant precedent for selecting thresholds like this. # Use cases - In Rails 8.1, `Array(only).map(&:to_s) & attribute_names` in `ActiveModel::Serialization#serializable_hash` filters a full attribute list with keys from the caller. - In Rails 8.1, Active Record collection replacement calls `intersection(new_target, original_target)`. The ordinary `HasManyAssociation` helper implements this as `a & b`; `HasManyThroughAssociation` uses a separate implementation. - Rails command lookup uses `lookups & namespaces.keys`. # Discussion ## Results The primary measurements ran on macOS arm64, with separate confirmation on Ubuntu 24.04 x86-64. Each comparison used the same Ruby commit with and without the patch. | Case | Benchmark case | Change | |---|---|---:| | ActiveModel shape, 6 and 50 strings | `attr-filter-6-and-50` | ~1.77x | | Collection replacement shape, 10 and 10,000 ids | `short-receiver-10-and-10k` | ~2.74x | On Linux, the same two shapes improved by 1.66x and 2.46x. Other id-list shapes moved by 1.11-1.23x there, but unchanged small-array cases moved by up to 1.16x in the same rounds, so I make no claim from those smaller deltas. With unmodified Rails 8.1 Active Model code, `ActiveModel#serializable_hash(only: 6 of 50 attributes)` improved from about 3.6 µs to about 2.8 µs per call. The control path without `only:` did not change. For memory, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. The scan still takes time proportional to the long array; the change removes the hash build from that array. The Rails 8.1.1 Lobsters workload entered the proposed branch 152 times across application boot and three iterations, mainly through Active Model serialization. Six alternating A/B batches found no detectable whole-workload change. ## Known trade-offs ### Arguments with many duplicates The threshold uses array lengths, not the number of distinct elements. A long argument with few distinct values can be cheap to hash. In tested cases at the exact `2x` threshold, throughput fell to about 0.64x on arm64 and about 0.90x on Linux. The mirrored case is slow on current Ruby: a short duplicate-heavy `self` with a long distinct argument improved by about 2.4x on arm64 and 1.6x on Linux with this patch. No choice based only on lengths can make both shapes faster. ### Hash collisions The new path makes hash quality on `self` more important; the current path makes hash quality on the argument more important. The worst-case complexity does not change, but the array that triggers it can change at the threshold. For example, 3,000 distinct elements in `self` with the same hash and a clean 6,000-element argument changed from about 0.5 ms to 63 ms. The reverse case changed from about 250 ms to 0.8 ms. `Array#intersect?` already makes the same trade when it chooses the shorter array. ### Custom `#hash` and `#eql?` Built-in integers, symbols, and strings cannot observe the call direction. User-defined methods can. The standard library provides an example with asymmetric `#eql?`: ```ruby require "delegate" string = "abc" delegator = SimpleDelegator.new(string) delegator.hash == string.hash # => true delegator.eql?(string) # => true string.eql?(delegator) # => false a = [delegator] + (1..20).map { |i| "x#{i}" } b = [string] + (1..100).map { |i| "y#{i}" } a & b # Current Ruby: [delegator], proposal: [] a.intersect?(b) # Current Ruby and proposal: false b & a # Current Ruby and proposal: [] ``` The proposal changes the first result and makes these three operations agree for this input. This agreement is not a compatibility guarantee. For values whose `#eql?` is symmetric, transitive, stable, and consistent with `#hash`, the result does not change. Logging, mutation, exceptions, object reachability, and GC timing can expose a different call order. These behaviors are not specified. ## Safety and tests Calls to user `#hash` and `#eql?` can mutate either array or run the GC. The candidate loop cannot write past the initial length of `self`. Candidate objects live in a Ruby array; the only raw buffer contains `bool` flags. Tests cover the `2x` boundary, both lookup paths, equality edge cases, mutation, and GC compaction. `ruby/test_array.rb` and `spec/ruby/core/array` pass. A randomized comparison with current Ruby produced the same results for normal values. Implementation: [one-commit fork branch](https://github.com/ruby/ruby/compare/master...kryzhovnik:array-and-…. It contains the change, the RDoc update, the tests, and the benchmarks. # See also - [ruby/ruby#14855](https://github.com/ruby/ruby/pull/14855) also chose an array by length, but did not preserve both the objects and order from `self`. - [Feature #15198] added `Array#intersect?`, which avoids materializing an intersection and can choose the hash side by length because it returns only a boolean. - [Feature #13884] added an existing size-based strategy choice for these methods. - [Bug #19622] led Ruby to document that these methods use both `#hash` and `#eql?`; it did not specify which operand receives the calls. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126356] [Ruby Feature#22238] String#tr to take a Hash for multi-character replacements
by byroot (Jean Boussier) 11 Sep '26

11 Sep '26

Issue #22238 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22238: String#tr to take a Hash for multi-character replacements https://bugs.ruby-lang.org/issues/22238 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- This is @matz's counter proposal to [Feature #22229] from the last dev-meeting > matz: I will counter-propose String#tr-with-hash style. ```ruby 'Hello </script>'.tr(">" => '\u003e', "<" => '\u003c', "&" => '\u0026') # matz: OK 'Hello </script>'.tr("abc" => 'ABC') # should raise an exception 'Hello </script>'.tr("abc" => 'ABC', "ab" => "XY") # should raise an exception "fée".tr("é" => "€") # it should work "Hello".tr("l" => "ABC", "o" => "XYZ") #=> "HeABCABCXYZ" "Hello".gsub(/./m) { hash[$&] || $& } # gsub equivalent ``` Notes: - Hash keys MUST be single characters (but can be multi-byte). - Values can be multiple characters. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:125416] [Ruby Feature#22056] Add zero-copy String constructor backed by an arbitrary Ruby object
by himura467 (Akito Shitara) 11 Sep '26

11 Sep '26

Issue #22056 has been reported by himura467 (Akito Shitara). ---------------------------------------- Feature #22056: Add zero-copy String constructor backed by an arbitrary Ruby object https://bugs.ruby-lang.org/issues/22056 * Author: himura467 (Akito Shitara) * Status: Open ---------------------------------------- ### Description Ruby has rich built-in functionality for working with byte sequences through `String`. Objects that manage their own byte buffers naturally want to expose their data through this interface. The straightforward approach is `rb_str_new()`, which copies the bytes: ``` c VALUE str = rb_str_new(str, len); ``` For large or frequently accessed buffers this copy is wasteful in both time and memory. One approach is to create a String that directly references the existing memory, with the GC keeping the owner alive for as long as the String is reachable. This avoids both the copy and the need for manual lifetime management. ### Existing APIs and their limitations | API | Memory behavior | | ---- | ---- | | `rb_str_new` / `rb_str_new_cstr` | Copies bytes; String owns the allocation | | `rb_str_new_shared` / `rb_str_new_frozen` | References another String's buffer; parent must be a String | | `rb_str_new_static` | References static (compile-time) storage; no lifetime management | `rb_str_new_static` avoids copying but is only safe for storage that lives forever. When memory is owned by a Ruby object, it is freed when that object is collected, and `rb_str_new_static` offers no way to express that dependency. The common workaround is to pin the owner via an instance variable: ``` c VALUE str = rb_str_new_static(str, len); rb_ivar_set(str, id_owner, owner); ``` This relies on undocumented GC behavior, incurs ivar table allocation overhead, and leaves lifetime management entirely to the caller. ### Proposal Add zero-copy String constructors that accept an explicit parent object. The proposed names are tentative and open for discussion (see below): ``` c VALUE rb_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_usascii_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_utf8_str_new_external(const char *ptr, long len, VALUE parent); VALUE rb_enc_str_new_external(const char *ptr, long len, rb_encoding *enc, VALUE parent); ``` `parent` can be any live Ruby object. The GC guarantees it is not collected before the returned String is. `ptr` must point into memory whose lifetime is tied to `parent`; no copy is made. ### Use cases *IO::Buffer#get_string* `IO::Buffer.for(string)` wraps a String's bytes in a READONLY EXTERNAL buffer. `IO::Buffer#get_string` now copies those bytes into a new String. With this API, the returned String can reference the source String directly: ``` c return rb_enc_str_new_external((const char *)base + offset, length, encoding, buffer->source); ``` The returned String holds a direct GC reference to the source String, so it remains valid even after the buffer is freed. *GLib::Bytes#to_s (ruby-gnome)* `GLib::Bytes` is an immutable, reference-counted byte buffer from GLib. The current [implementation](https://github.com/ruby-gnome/ruby-gnome/blob/1dad74d1a86f9… uses the ivar workaround: ``` c VALUE str = rb_str_new_static(data, size); rb_iv_set(str, "@bytes", self); ``` With the proposed API this becomes: ``` c return rb_str_new_external(data, size, self); ``` ### Open questions *Naming* The name `rb_str_new_external` is one option. Other candidates: * `rb_str_new_owned_by` / `rb_enc_str_new_owned_by` * `rb_str_new_pinned` / `rb_enc_str_new_pinned` * `rb_str_new_with_parent` / `rb_enc_str_new_with_parent` *Memory retention* When a String referencing a small slice of a large buffer remains reachable, the entire backing object is kept alive. This is the same concern that led Java to remove the shared-backing optimization from `String.substring()` in Java 7. The risk was also raised in the context of Ruby's own lazy substring proposal (#19315, https://bugs.ruby-lang.org/issues/19315#note-7) > I heard that Java stopped the shared substring technique 10 years ago (https://www.infoq.com/news/2013/12/Oracle-Tunes-Java-String/) because of the potential for memory leaks > > I don't disagree this proposal, but it would be nice if we could evaluate the effectiveness of this optimization. Whether the same concern applies to this proposal, and whether the API should offer a way to force an independent copy, is worth discussing. ### Proof of concept A prototype implementation is at: https://github.com/ruby/ruby/pull/16834 The implementation introduces a new flag on non-embedded strings and stores the parent reference in `RString.as.heap.aux.parent`. The GC mark phase pins embedded parent strings to prevent compaction from invalidating the raw pointer stored in the zero-copy child. -- https://bugs.ruby-lang.org/

7 28

[ruby-core:126506] [Ruby Feature#22266] Stop warning for duplicate keywords in splatted literal hashes
by jeremyevans0 (Jeremy Evans) 10 Sep '26

10 Sep '26

Issue #22266 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #22266: Stop warning for duplicate keywords in splatted literal hashes https://bugs.ruby-lang.org/issues/22266 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- Ruby warns for duplicate keywords in the same literal hash: ```shellsession $ ruby -we '{h: 1, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` Ruby does not warn for duplicate keywords in splatted hashes: ```shellsession $ ruby -we 'h = {h:}; {h:, **h}' $ ruby -we 'h = {h:}; {**h, h:}' $ ruby -we 'h = {h:}; {**h, h:, **h}' $ ruby -we 'h = {h:}; {**h, **h}' ``` However, Ruby warns for for duplicate keywords in splatted literal hashes: ```shellsession $ ruby -we '{h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1}' -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, h: 1, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 -e:1: warning: key :h is duplicated and overwritten on line 1 $ ruby -we '{**{h: 1}, **{h: 1}}' -e:1: warning: key :h is duplicated and overwritten on line 1 ``` I think Ruby should stop warning in the splatted literal hash case, for two reasons: * Treatment of splatted literal hashes is inconsistent with treatment of splatted non-literal hashes. Even if the compiler optimizes the splatted literal hash to the same bytecode as a direct keyword, it should not emit the same warning, because fundamentally the duplicate keyword is in a different hash, not in the same hash. * Warnings are designed to be helpful to the programmer, but unlike the warning for duplicate keywords in the same hash (a common mistake), no Ruby programmer is going to write splatted literal hashes. I can see an automated program generating splatted literal hashes, but in that case, the warnings are likely to be undesirable, just as warning for duplicate keywords in splatted non-literal hashes would be undesirable. Consider a hypothetical future Ruby compiler that could optimize the `h = {h:}; {h:, **h}` to the same bytecode as `{h: nil, **{h: nil}}`. Would we still want to emit the same warning? If accepted, I'm happy to work on a patch to implement this. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:126458] [Ruby Feature#22255] Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select
by ko1 (Koichi Sasada) 10 Sep '26

10 Sep '26

Issue #22255 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22255: Add `timeout:` to Ractor::Port#receive, Ractor.receive and Ractor.select https://bugs.ruby-lang.org/issues/22255 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- ## Abstract Add a `timeout:` keyword to the three ways a Ractor waits for a message: ```ruby Ractor::Port#receive(timeout: nil) # -> msg or nil Ractor.receive(timeout: nil) # -> msg or nil Ractor.select(*ports, timeout: nil) # -> [port, msg] or nil ``` They return `nil` once the timeout passes. `timeout: 0` never blocks: it takes a message if one is already there and returns `nil` otherwise. ## Background Today a Ractor wait cannot be bounded. Once a Ractor calls `receive`, it waits until a message arrives, so there is no way to write * a worker that gives up and reports progress if nothing arrives for a while, * a shutdown that stops waiting after a grace period, * a non-blocking "is there anything for me?" check. The usual workarounds are worse than a timeout: a watchdog Ractor that sends a dummy message, or a helper thread that closes the port. Both add a Ractor or a thread per wait and change the shape of the program. Every other blocking wait in Ruby already has this: `Thread::Queue#pop(timeout:)`, `ConditionVariable#wait(mutex, timeout)`, `Thread#join(limit)`, `IO#wait(timeout)`, `Mutex#sleep(timeout)`. ## Specification | call | result | |---|---| | `port.receive` | blocks until a message arrives (unchanged) | | `port.receive(timeout: 1.5)` | the message, or `nil` after 1.5 seconds | | `port.receive(timeout: 0)` | the message if one is already queued, else `nil`, without blocking | | `port.receive(timeout: -1)` | `ArgumentError` | | `Ractor.select(a, b, timeout: 1.5)` | `[port, msg]`, or `nil` after 1.5 seconds | The timeout behaves as it does elsewhere in Ruby: `nil` when it passes, and `timeout: 0` polls without blocking, as in `Thread::Queue#pop(timeout:)`, `IO.select` and `IO#wait`. * `timeout` accepts what `sleep` accepts (Integer, Float, Rational); a non-numeric value raises `TypeError`. * A negative timeout raises `ArgumentError`, as `IO.select` does. Note that `Thread::Queue#pop(timeout: -1)` instead returns `nil` right away, so the two existing APIs already disagree here; this follows `IO.select`. * `timeout: nil` (the default) means no timeout, i.e. today's behaviour. * A closed port still raises `Ractor::ClosedError`, timeout or not. * The timeout bounds how long the call blocks; it does not cut delivery off. A message that arrives while the timeout is being reported is still returned. Nothing is lost either way: a message only leaves the queue when it is returned. ### Why `nil` `nil` on timeout is what `Thread::Queue#pop(timeout:)`, `IO.select`, `IO#wait` and `Thread#join` all return. It is ambiguous when `nil` itself is a valid message, which is the same ambiguity `Queue#pop` has. The alternatives are a new exception class (`Ractor::TimeoutError`) or a sentinel object; both were judged heavier than the ambiguity is worth, but this is worth confirming. ### Why `timeout: 0` rather than a separate `try_receive` `timeout: 0` covers the non-blocking case with no new method name, and it is a genuine fast path in the implementation: it converts nothing, reads no clock and never parks. It costs about what a `receive` of an already-waiting message costs (~70ns vs ~150ns in a micro benchmark), against ~1.7us for a `receive(timeout: 10)` that has to compute a deadline. ## Implementation The wait stays where it is. `rb_ractor_sched_wait()` keeps parking the thread in the thread scheduler, so **an M:N thread still hands its native thread back** instead of becoming a dedicated one. Measured with 50 Ractors waiting at once, a timed `receive` uses the same 18 native threads an untimed one does. How the deadline is taken depends on the thread: * A **dedicated native thread** parks on its own condvar, so it takes the deadline there, the way `native_cond_sleep()` does. The condvar it waits on is the one a send already signals, so nothing else is involved. * An **M:N thread** has no condvar of its own, so its deadline is armed on the timer thread as a timeout-only wheel entry. The timer thread then wakes it through `thread_sched_to_ready_common()`, which is exactly how a send wakes it. That gives an M:N waiter two wakers, so the send path takes an armed timeout back before waking, skips a thread a fired timeout already made runnable, and bumps the scheduler event serial so a timeout that has not fired cannot wake it twice. Both kinds of wait exist on every pthread platform, including builds without the timer wheel (`USE_MN_THREADS == 0`, e.g. s390x-linux), where every thread is dedicated. On win32 the wait is already a condvar wait, which takes the timeout directly. Timer resolution follows the thread kind, exactly as `sleep` already does on the same thread: a dedicated thread gets the condvar's resolution, an M:N thread gets the timer wheel's 1ms tick. Measured, `receive(timeout: 0.0002)` and `sleep(0.0002)` return in 0.275ms on the main thread and 1.15ms inside a Ractor. ## Verification Besides `test/ruby/test_ractor.rb` additions: an attack suite of 13 scenarios (timeout racing with send, `Port#close`, `Thread#kill`, `Thread#raise`, Ractor termination, GC and compaction, `fork`, 64 waiters expiring in the same instant, all-Ractors-waiting deadlock detection) and a sweep that injects a trap, `SIGINT`, `Thread#kill` and `Thread#raise` at four points of the wait, including the instant the timer fires. Run against a release build, a `VM_CHECK_MODE` build and a `USE_MN_THREADS=0` build, with `RUBY_MN_THREADS=0` and `=1`. Of ~120,000 interrupt injections, ~78,000 landed while the thread was parked: no missed wakeup, no wait cut short by a trap, no assertion. 2,000,000 arm/disarm cycles showed no timer-wheel growth. ## Open questions 1. `nil` on timeout, or a `Ractor::TimeoutError`? 1a. A negative timeout: `ArgumentError` as in `IO.select`, or `nil` as in `Thread::Queue#pop`? 2. Should `Ractor.select` return something other than `nil`, given it already returns an Array? ## Patch https://github.com/ruby/ruby/pull/18418 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125247] [Ruby Bug#21995] mkmf generates a non-deterministic log file
by gemmaro (Gemma Kosaka) 10 Sep '26

10 Sep '26

Issue #21995 has been reported by gemmaro (Gemma Kosaka). ---------------------------------------- Bug #21995: mkmf generates a non-deterministic log file https://bugs.ruby-lang.org/issues/21995 * Author: gemmaro (Gemma Kosaka) * Status: Open * ruby -v: ruby 4.1.0dev (2026-04-12T14:25:33Z master 6593cc52d6) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, When compiling Ruby's C extensions with mkmf, it can generate a `mkmf.log` file with non-deterministic content, especially at the line below: ```txt ld: /tmp/rubytest.h8pay9/cc3fbuGm.o: in function `t': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This can be problematic on some distributions/package-managers, since the `mkmf.log` file is included in the files generated by `gem install`. {{collapse(example flow) Note about an example flow where randomized filenames occur: 1. `extconf.rb` has calls to `have_func` 2. `gem install` is run by the user 3. It invokes mkmf to process the `extconf.rb` file 4. The checks fail and print intermediate randomized filenames, which are recorded in `mkmf.log` file 5. `gem install` includes `mkmf.log` in the packaged files 6. When the gem is built/packaged multiple times, a reproducibility problem occurs }} {{collapse(background) As a background, the previously reported/related issues are: * ##15304 * This mentions temporary filenames in the generated Makefile, and they are not reproducible. * The necessity/value of including `Makefile`, `gem_make.out`, and `mkmf.log` files are questioned. * So the [pull request](https://github.com/ruby/rubygems/pull/2481) was created to omit these files when installing gems. * However, deleting these files might break compatibility, so the pull request was closed. * Note: There is an [entry](https://github.com/ruby/rubygems/blob/3e3addb8d222d23ac46ca3b1959b29… about `mkmf.log` in the RubyGems' changelog: > ## 2.2.2 / 2014-02-05 > > ### Bug fixes: > > * [...] > * The `mkmf.log` is now placed next to `gem_make.out` when building extensions. * ##19329 * This points out that `gem install` installs `mkmf.log` file. * It was [transferred](https://github.com/ruby/rubygems/issues/6259) at RubyGems GitHub repository. * There are some issues related to this topic on the GNU Guix channel * For example, when I was packaging Ruby 4.0 for Guix, this reproducibility problem [occured](https://codeberg.org/guix/guix/pulls/5166). * There should be other workarounds in the Nix community, apparently. }} To wrap up, I think the followings are desirable: * Conventional file locations should be kept as is on the RubyGems side. * Just deleting these files breaks compatibilities. * These might be helpful when users report issues to gem owners with detailed information. * It is helpful if generated file contents are as reproducible as possible. * In some contexts where reproducibility matters, this issue makes packaging Ruby gems a bit harder. * Luckily, workarounds are possible in distribution package recipes such as deleting these files. * -> the component that generates `mkmf.log` is mkmf, so it might be resolvable by modifying mkmf itself. Thank you, gemmaro. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:126293] [Ruby Feature#22232] Deprecate `RHASH_TBL` and associated APIs
by byroot (Jean Boussier) 10 Sep '26

10 Sep '26

Issue #22232 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22232: Deprecate `RHASH_TBL` and associated APIs https://bugs.ruby-lang.org/issues/22232 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- I would like to deprecate `RHASH_TBL` and `RHASH_TBL_RAW`. ### Problem These API take a `RHash` instance and return its associated `st_table *`. If the Hash isn't backed by an `st_table` it will force convert it. I think it's a bad API because: - It allows to mutate the hash without triggering write barriers (dangerous). - Using it on a Hash backed by an `ar_table` blow memory usage. - It restrict evolution of RHash, as we must always be able to convert a Hash into a public `st_table`. There are various optimizations that would make sense for `RHash` but that would break the public `ruby/st.h` API, as such, in the future we may want to essentially fork `ruby/st.h` to have a distinct internal version dedicated to `RHash`. Just to give an example, `st_table.type` is very wasteful for RHash, as it's a full length 8B pointer that has only 2 possible values. It would be way more efficient to pass it as an argument every time, and get rid of some pointer chasing. With the possible future introduction of arbitrary length allocation in the GC, we might also want RHash to allocate its bins and entries with the GC rather than malloc. Both those ideas aren't possible to implement (or much harder) if we need to support `RHASH_TBL`. ### Impact I need to figure out how to use the gem search server, but a preliminary search on GitHub didn't show a lot of usage, it's a relatively rare API and if there are use cases that currently necessitate using `st_*` functions on RHash we should define equivalent `rb_hash_` functions to replace them. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:126507] [Ruby Bug#22267] Active Support tests started failing on ruby master (bisected to #18194)
by yahonda (Yasuo Honda) 10 Sep '26

10 Sep '26

Issue #22267 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22267: Active Support tests started failing on ruby master (bisected to #18194) https://bugs.ruby-lang.org/issues/22267 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-26T07:05:32Z master 346b261abe) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- On ruby-head, the Active Support (Rails) test suite fails with two Ractor-related errors (rails-nightly build 4651, https://buildkite.com/rails/rails-nightly/builds/4651#01a016ac-eada-492d-95…) Rails CI failure. To reproduce on the Rails side, build ruby master, then in a rails/rails checkout run the two tests from activesupport/: ``` $ ruby -v ruby 4.1.0dev (2026-08-26T07:05:32Z master 346b261abe) +PRISM [x86_64-linux] $ bundle exec ruby -Ilib:test test/time_zone_test.rb -n test_formatted_offset_in_ractor #<Thread:...> terminated with exception (report_on_exception is true): lib/active_support/time_with_zone.rb:78:in 'ActiveSupport::TimeWithZone#period': undefined method 'period_for_utc' for nil (NoMethodError) from lib/active_support/time_with_zone.rb:139:in 'ActiveSupport::TimeWithZone#zone' from lib/active_support/time_with_zone.rb:59:in 'ActiveSupport::TimeWithZone#initialize' from lib/active_support/time_with_zone.rb:535:in 'ActiveSupport::TimeWithZone#marshal_load' 1) Error: TimeZoneTest#test_formatted_offset_in_ractor: Ractor::RemoteError: thrown by remote Ractor. lib/active_support/testing/ractors_assertions.rb:15:in 'Ractor#join' lib/active_support/testing/ractors_assertions.rb:15:in 'ActiveSupport::Testing::RactorsAssertions#on_ractor' test/time_zone_test.rb:895:in 'TimeZoneTest#test_formatted_offset_in_ractor' $ bundle exec ruby -Ilib:test test/notifications_test.rb -n test_record_and_set_subscriptions_when_using_a_regexp 1) Error: Notifications::NotificationSubscriptionTest#test_record_and_set_subscriptions_when_using_a_regexp: Ractor::Error: can not copy Hash object. lib/active_support/ractors.rb:117:in 'Ractor.make_shareable' lib/active_support/ractors.rb:117:in 'ActiveSupport::Ractors.make_shareable' lib/active_support/ractors.rb:79:in 'ActiveSupport::Ractors.try_make_shareable' lib/active_support/notifications.rb:359:in 'ActiveSupport::Notifications.record_subscriptions' lib/active_support/notifications.rb:314:in 'ActiveSupport::Notifications.subscribe' test/notifications_test.rb:604:in 'block in <class:NotificationSubscriptionTest>' ``` git bisect points at #18194 (Per-Ractor GC). Both reduce to Ractor copy and reproduce without Rails. Steps to reproduce (pure Ruby). (1) mirrors TimeZoneTest#test_formatted_offset_in_ractor — an object with a Time ivar (which now forces a Marshal fallback) whose marshal_load reconstructs from state only reachable in the main Ractor: ``` class Registry @zones = { "z" => Object.new } def self.find(name) = @zones.fetch(name) # reads a class-level ivar end class Wrapper def initialize(name) = (@name = name; @time = Time.now; @zone = Registry.find(name)) def marshal_dump = @name def marshal_load(name) = (@name = name; @time = Time.now; @zone = Registry.find(name)) end port = Ractor::Port.new Ractor.new(port, Wrapper.new("z")) { |p, o| p.send :ok }.join p port.receive ``` (2) mirrors Notifications...test_record_and_set_subscriptions_when_using_a_regexp — a Hash holding a Set and a shareable Proc: ``` require "set" Ractor.make_shareable({ s: Set.new([1, 2]), p: Ractor.shareable_proc {} }, copy: true) ``` Expected behavior. On Ruby 4.0.6 and before #18194 (50745e3e48): - (1) copies natively, marshal_load is not called, and prints :ok. - (2) succeeds. Actual behavior. On current master (346b261abe) and since #18194 (4f6c34eea6): (1): ``` #<Thread:...> terminated with exception (report_on_exception is true): -:3:in 'Registry.find': can not get unshareable values from instance variables of classes/modules from non-main Ractors (@zones from Registry) (Ractor::IsolationError) from -:8:in 'Wrapper#marshal_load' -:11:in 'Ractor#join': thrown by remote Ractor. (Ractor::RemoteError) from -:11:in '<main>' ``` marshal_load now runs in the receiver Ractor, where the object cannot reach main-Ractor state. In Active Support the same happens in TimeWithZone#marshal_load; there Time.find_zone rescues this and returns nil, so the Rails trace shows period_for_utc for nil instead. (2): ``` -:2:in 'Ractor.make_shareable': can not copy Hash object. (Ractor::Error) from -:2:in '<main>' -:2:in 'Ractor.make_shareable': no _dump_data is defined for class Proc (TypeError) from -:2:in '<main>' ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:122943] [Ruby Bug#21537] rb_ractor_sched_barrier_start() hangs on Windows
by rhenium (Kazuki Yamaguchi) 09 Sep '26

09 Sep '26

Issue #21537 has been reported by rhenium (Kazuki Yamaguchi). ---------------------------------------- Bug #21537: rb_ractor_sched_barrier_start() hangs on Windows https://bugs.ruby-lang.org/issues/21537 * Author: rhenium (Kazuki Yamaguchi) * Status: Open * ruby -v: ruby 3.5.0dev (2025-08-09T11:32:53Z master 2a6345e957) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following script hangs at `GC.start` indefinitely. Pressing Ctrl+C on the terminal interrupts the `sleep` and it appears to resume and prints "in_ractor". ```ruby Ractor.new { sleep 1 GC.start puts "in_ractor" } sleep ``` I also reproduced this with Ruby 3.0.7 from RubyInstaller2. Here is the stack trace with master: ``` 0:006> ~*k 0 Id: 1e88.36c4 Suspend: 1 Teb: 000000c6`92478000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`929fef18 00007ffa`9e4edf43 ntdll!NtWaitForMultipleObjects+0x14 01 000000c6`929fef20 00007ffa`9e4ede11 KERNELBASE!WaitForMultipleObjectsEx+0x123 02 000000c6`929ff210 00007ff6`756b8164 KERNELBASE!WaitForMultipleObjects+0x11 03 000000c6`929ff250 00007ff6`756b13af miniruby!w32_wait_events+0x108 [C:\w\ruby\thread_win32.c @ 239] 04 000000c6`929ff2d0 00007ff6`756b62a2 miniruby!native_sleep+0xc3 [C:\w\ruby\thread_win32.c @ 360] 05 000000c6`929ff310 00007ff6`75646353 miniruby!sleep_forever+0x82 [C:\w\ruby\thread.c @ 1374] 06 000000c6`929ff350 00007ff6`756e5f4b miniruby!rb_f_sleep+0x53 [C:\w\ruby\process.c @ 4975] 07 000000c6`929ff380 00007ff6`756e5df9 miniruby!vm_call_cfunc_with_frame_+0x14b [C:\w\ruby\vm_insnhelper.c @ 3850] 08 000000c6`929ff460 00007ff6`756e5dbb miniruby!vm_call_cfunc_with_frame+0x29 [C:\w\ruby\vm_insnhelper.c @ 3895] 09 000000c6`929ff4a0 00007ff6`756e5ab7 miniruby!vm_call_cfunc_other+0xc7 [C:\w\ruby\vm_insnhelper.c @ 3922] 0a 000000c6`929ff4e0 00007ff6`756e8363 miniruby!vm_call_cfunc+0x10b [C:\w\ruby\vm_insnhelper.c @ 4003] 0b 000000c6`929ff510 00007ff6`756e7cfe miniruby!vm_call_method_each_type+0x637 [C:\w\ruby\vm_insnhelper.c @ 4827] 0c 000000c6`929ff610 00007ff6`756f39b4 miniruby!vm_call_method+0x152 [C:\w\ruby\vm_insnhelper.c @ 4991] 0d 000000c6`929ff680 00007ff6`756ee003 miniruby!vm_sendish+0x1f4 [C:\w\ruby\vm_insnhelper.c @ 6065] 0e 000000c6`929ff700 00007ff6`756e0f27 miniruby!vm_exec_core+0x25cb [C:\w\ruby\insns.def @ 900] 0f (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 10 000000c6`929ff860 00007ff6`755b896f miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 11 000000c6`929ff9d0 00007ff6`755baf47 miniruby!rb_ec_exec_node+0x10f [C:\w\ruby\eval.c @ 284] 12 000000c6`929ffb50 00007ff6`75531069 miniruby!ruby_run_node+0x43 [C:\w\ruby\eval.c @ 320] 13 (Inline Function) --------`-------- miniruby!rb_main+0x25 [C:\w\ruby\main.c @ 42] 14 (Inline Function) --------`-------- miniruby!w32_main+0x5f [C:\w\ruby\main.c @ 62] 15 000000c6`929ffb80 00007ff6`7575e3ec miniruby!wmain+0x69 [C:\w\ruby\main.c @ 48] 16 (Inline Function) --------`-------- miniruby!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 17 000000c6`929ffbb0 00007ffa`a03de8d7 miniruby!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 18 000000c6`929ffbf0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 19 000000c6`929ffc20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 1 Id: 1e88.1468 Suspend: 1 Teb: 000000c6`9247a000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`92dff618 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`92dff620 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`92dff980 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`92dff9b0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 2 Id: 1e88.1058 Suspend: 1 Teb: 000000c6`9247c000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`931ff6a8 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`931ff6b0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`931ffa10 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`931ffa40 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 3 Id: 1e88.158c Suspend: 1 Teb: 000000c6`9247e000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`935ff998 00007ffa`a103259e ntdll!NtWaitForWorkViaWorkerFactory+0x14 01 000000c6`935ff9a0 00007ffa`a03de8d7 ntdll!TppWorkerThread+0x37e 02 000000c6`935ffd00 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`935ffd30 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 4 Id: 1e88.3acc Suspend: 1 Teb: 000000c6`92480000 Unfrozen "ruby-timer-thread" # Child-SP RetAddr Call Site 00 000000c6`936ffbc8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`936ffbd0 00007ff6`756b7e9d KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`936ffc70 00007ffa`9e0d37b0 miniruby!timer_thread_func+0x45 [C:\w\ruby\thread_win32.c @ 777] 03 000000c6`936ffca0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 04 000000c6`936ffcd0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 05 000000c6`936ffd00 00000000`00000000 ntdll!RtlUserThreadStart+0x2c 5 Id: 1e88.2934 Suspend: 1 Teb: 000000c6`92482000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`937ff4f8 00007ffa`9e4ecbbf ntdll!NtWaitForSingleObject+0x14 01 000000c6`937ff500 00007ff6`756b1276 KERNELBASE!WaitForSingleObjectEx+0xaf 02 000000c6`937ff5a0 00007ff6`756f7f47 miniruby!native_cond_timedwait_ms+0x62 [C:\w\ruby\thread_win32.c @ 483] 03 (Inline Function) --------`-------- miniruby!vm_cond_wait+0x28 [C:\w\ruby\vm_sync.c @ 211] 04 000000c6`937ff5f0 00007ff6`756b2c83 miniruby!rb_vm_cond_wait+0x37 [C:\w\ruby\vm_sync.c @ 220] 05 000000c6`937ff620 00007ff6`756f7f02 miniruby!rb_ractor_sched_barrier_start+0x67 [C:\w\ruby\thread_win32.c @ 956] 06 000000c6`937ff650 00007ff6`755c7a78 miniruby!rb_vm_barrier+0x1e [C:\w\ruby\vm_sync.c @ 265] 07 (Inline Function) --------`-------- miniruby!rb_gc_vm_barrier+0x5 [C:\w\ruby\gc.c @ 179] 08 (Inline Function) --------`-------- miniruby!gc_enter+0x25 [C:\w\ruby\gc\default\default.c @ 6609] 09 000000c6`937ff680 00007ff6`755c442e miniruby!gc_start+0xc0 [C:\w\ruby\gc\default\default.c @ 6334] 0a 000000c6`937ff6e0 00007ff6`755cdd0f miniruby!garbage_collect+0x42 [C:\w\ruby\gc\default\default.c @ 6316] 0b 000000c6`937ff710 00007ff6`755c2cc3 miniruby!rb_gc_impl_start+0x4b [C:\w\ruby\gc\default\default.c @ 6767] 0c 000000c6`937ff740 00007ff6`756d5c7b miniruby!gc_start_internal+0x4f [C:\w\ruby\gc.c @ 3447] 0d 000000c6`937ff780 00007ff6`756ee237 miniruby!builtin_invoker4+0x23 [C:\w\ruby\vm_insnhelper.c @ 7373] 0e (Inline Function) --------`-------- miniruby!invoke_bf+0x32 [C:\w\ruby\vm_insnhelper.c @ 7485] 0f (Inline Function) --------`-------- miniruby!vm_invoke_builtin+0x32 [C:\w\ruby\vm_insnhelper.c @ 7493] 10 000000c6`937ff7c0 00007ff6`756e0f27 miniruby!vm_exec_core+0x27ff [C:\w\ruby\build-debug\vm.inc @ 4621] 11 (Inline Function) --------`-------- miniruby!vm_exec_loop+0x8 [C:\w\ruby\vm.c @ 2653] 12 000000c6`937ff920 00007ff6`756f08b0 miniruby!rb_vm_exec+0x10b [C:\w\ruby\vm.c @ 2624] 13 (Inline Function) --------`-------- miniruby!invoke_iseq_block_from_c+0x1e3 [C:\w\ruby\vm.c @ 1651] 14 (Inline Function) --------`-------- miniruby!invoke_block_from_c_proc+0x2f2 [C:\w\ruby\vm.c @ 1745] 15 000000c6`937ffa90 00007ff6`756b6bf9 miniruby!vm_invoke_proc+0x324 [C:\w\ruby\vm.c @ 1775] 16 000000c6`937ffbd0 00007ff6`756b7987 miniruby!thread_do_start_proc+0x131 [C:\w\ruby\thread.c @ 584] 17 (Inline Function) --------`-------- miniruby!thread_do_start+0x37 [C:\w\ruby\thread.c @ 626] 18 000000c6`937ffc40 00007ff6`756b7720 miniruby!thread_start_func_2+0x243 [C:\w\ruby\thread.c @ 677] 19 000000c6`937ffe90 00007ffa`9e0d37b0 miniruby!thread_start_func_1+0x74 [C:\w\ruby\thread_win32.c @ 659] 1a 000000c6`937ffec0 00007ffa`a03de8d7 ucrtbase!thread_start<unsigned int (__cdecl*)(void *),1>+0x30 1b 000000c6`937ffef0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 1c 000000c6`937fff20 00000000`00000000 ntdll!RtlUserThreadStart+0x2c # 6 Id: 1e88.4f4 Suspend: 1 Teb: 000000c6`92486000 Unfrozen # Child-SP RetAddr Call Site 00 000000c6`93bff768 00007ffa`a10d793e ntdll!DbgBreakPoint 01 000000c6`93bff770 00007ffa`a03de8d7 ntdll!DbgUiRemoteBreakin+0x4e 02 000000c6`93bff7a0 00007ffa`a0fdc34c KERNEL32!BaseThreadInitThunk+0x17 03 000000c6`93bff7d0 00000000`00000000 ntdll!RtlUserThreadStart+0x2c ``` -- https://bugs.ruby-lang.org/

3 2