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

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

07 Mar '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 6

[ruby-core:124741] [Ruby Bug#21873] `UnboundMethod#==` returns false for methods obtained via extend + unbind
by mdalessio (Mike Dalessio) 07 Mar '26

07 Mar '26

Issue #21873 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #21873: `UnboundMethod#==` returns false for methods obtained via extend + unbind https://bugs.ruby-lang.org/issues/21873 * Author: mdalessio (Mike Dalessio) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description `UnboundMethod#==` returns `false` when comparing a module's instance method against the same method obtained via `Method#unbind` on a class that includes or extends that module, despite having the same owner and source location. ```ruby module MyMethods def hello = "hello" end class Base extend MyMethods end from_module = MyMethods.instance_method(:hello) from_unbind = Base.method(:hello).unbind p from_module.owner == from_unbind.owner #=> true p from_module.source_location == from_unbind.source_location #=> true p from_module.inspect == from_unbind.inspect #=> true p from_module == from_unbind #=> false (expected true) ``` ## Diagnosis `method_eq` compares method entries using `method_entry_defined_class`. For methods mixed in via `include`/`extend`, the "defined class" will be an ICLASS and not the original class/module. In the example above, `method_eq` is comparing a module's ICLASS entry against the module, and that will always be false. Related: #18798 (fixed by @ko1 in 59e389af). -- https://bugs.ruby-lang.org/

6 6

[ruby-core:124673] [Ruby Bug#21860] Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup`
by byroot (Jean Boussier) 07 Mar '26

07 Mar '26

Issue #21860 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21860: Process.fork: the child may deadlock on `th->interrupt_lock` in `threadptr_interrupt_exec_cleanup` https://bugs.ruby-lang.org/issues/21860 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- We recently observed some deadlocked processes. These got deadlock during child initialization right after `Process.fork`. Based on the `gdb` session, the child is deadlocked in `threadptr_interrupt_exec_cleanup`, which suggest `th->interrupt_lock` was locked by another thread in the parent, and wasn't reinitialized in the children before calling `threadptr_interrupt_exec_cleanup`. ```c (gdb) bt 20 #0 0x0000ffff855a09c0 in __lll_lock_wait () from /lib64/libc.so.6 #1 0x0000ffff855a6d60 in pthread_mutex_lock@@GLIBC_2.17 () from /lib64/libc.so.6 #2 0x0000aaaaaeec04c8 [PAC] in rb_native_mutex_lock (lock=<optimized out>) at /ruby-3.4.4/thread_pthread.c:116 #3 threadptr_interrupt_exec_cleanup (th=<optimized out>) at thread.c:6052 #4 thread_cleanup_func_before_exec (th_ptr=0xffff35803000) at thread.c:514 #5 thread_cleanup_func (atfork=1, th_ptr=0xffff35803000) at thread.c:524 #6 terminate_atfork_i (current_th=0xffff84e1e000, th=0xffff35803000) at thread.c:4769 #7 rb_thread_atfork_internal (atfork=<optimized out>, th=0xffff84e1e000) at thread.c:4736 #8 rb_thread_atfork () at thread.c:4779 #9 0x0000aaaaaee110fc [PAC] in after_fork_ruby (pid=0) at process.c:1693 #10 rb_fork_ruby (status=status@entry=0x0) at process.c:4253 #11 0x0000aaaaaee11154 [PAC] in proc_fork_pid () at process.c:4266 #12 rb_proc__fork (_obj=<optimized out>) at process.c:4313 #13 0x0000aaaaaeefeb7c [PAC] in vm_call_cfunc_with_frame_ (stack_bottom=0xffff84e7a1c8, argv=0xffff84e7a1d0, argc=0, calling=<optimized out>, reg_cfp=0xffff84f79150, ec=0xffff84e31050) at /ruby-3.4.4/vm_insnhelper.c:3794 #14 vm_call_cfunc_with_frame (ec=0xffff84e31050, reg_cfp=0xffff84f79150, calling=<optimized out>) at /ruby-3.4.4/vm_insnhelper.c:3840 #15 0x0000aaaaaef1aa44 [PAC] in vm_sendish (method_explorer=<optimized out>, block_handler=<optimized out>, cd=<optimized out>, reg_cfp=<optimized out>, ec=<optimized out>) at /ruby-3.4.4/vm_callinfo.h:415 #16 vm_exec_core (ec=0xffff84e31050) at /ruby-3.4.4/insns.def:1063 #17 0x0000aaaaaef0aa58 [PAC] in rb_vm_exec (ec=ec@entry=0xffff84e31050) at vm.c:2595 #18 0x0000aaaaaef0fe48 [PAC] in vm_call0_body (ec=ec@entry=0xffff84e31050, calling=calling@entry=0xffffea5a1e78, argv=argv@entry=0x0) at /ruby-3.4.4/vm_eval.c:225 #19 0x0000aaaaaef136e8 in vm_call0_cc (kw_splat=0, cc=0xfffeee654508, argv=<optimized out>, argc=0, id=27393, recv=281472906794680, ec=0xffff84e31050) at /ruby-3.4.4/vm_eval.c:101 ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124699] [Ruby Bug#21866] Backport Fix for integer overflow checks in enumerator
by rwstauner (Randy Stauner) 07 Mar '26

07 Mar '26

Issue #21866 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #21866: Backport Fix for integer overflow checks in enumerator https://bugs.ruby-lang.org/issues/21866 * Author: rwstauner (Randy Stauner) * Status: Open * Assignee: rwstauner (Randy Stauner) * Target version: 4.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- I would like to backport this PR https://github.com/ruby/ruby/pull/15829 that has already merged to master. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123913] [Ruby Bug#21711] Prism and parse.y parses private endless method definition with block differently
by tompng (tomoya ishida) 07 Mar '26

07 Mar '26

Issue #21711 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21711: Prism and parse.y parses private endless method definition with block differently https://bugs.ruby-lang.org/issues/21711 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In the following code, `do end` block is passed to `private` in Prism but passed to `tap` in parse.y ~~~ruby private def f = tap do end f # different result(prism: LocalJumpError, parsey: returns main) ~~~ According to https://bugs.ruby-lang.org/issues/17398#note-10, `private def hello = puts "Hello" do expr end` should be parsed as `private (def hello = puts "Hello") do expr end`. This is correctly implemented in both Prism and parse.y, but when rhs is `tap do end`, there is a discrepancy. Another example. Prism: parse success, parse.y: syntax error. ~~~ruby private def f = 1 do end ~~~ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124864] [Ruby Misc#21922] Permissions for committers for default/bundled/unbundled gems repositories
by Eregon (Benoit Daloze) 06 Mar '26

06 Mar '26

Issue #21922 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21922: Permissions for committers for default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/curses * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/iconv * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-ftp * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (marked as maintained by @akr but they don't reply on GitHub, there is also an unclear relation with core Pathname [which still hasn't been resolved](https://github.com/ruby/pathname/issues/66) and is causing warnings for months) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set * https://github.com/ruby/shell * https://github.com/ruby/syck * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tk * https://github.com/ruby/tracer * https://github.com/ruby/webrick * https://github.com/ruby/win32api * https://github.com/ruby/xmlrpc This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afa… - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)) I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)) which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121627] [Ruby Feature#21264] Extract Date library from Ruby repo in the future
by hsbt (Hiroshi SHIBATA) 06 Mar '26

06 Mar '26

Issue #21264 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21264: Extract Date library from Ruby repo in the future https://bugs.ruby-lang.org/issues/21264 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- Note: This is not for Ruby 3.5. `Date` and `DateTime` has no primary maintainer in 10+ years. I would like to deprecate `date` via bundled gems for reducing our maintenance time especially @nobu. But `Time.prase` and `Time.strptime` are widely used now. How do we deprecate `date` library? 1. Migrate `Date._strptime`, `Date.strptime` and `Date._parse` to `Time`. The current `Date` is migrated as bundled gems. 2. Migrate `Date` to the bundled gems. `Time.parse` and `Time.strptime` warns if `date` is not found. 3. Keep the current situation 4. ... Does anyone have another idea? -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124928] [Ruby Feature#21943] Add StringScanner#get_int to extract capture group as Integer without intermediate String
by jinroq (Jinroq SAITOH) 06 Mar '26

06 Mar '26

Issue #21943 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21943: Add StringScanner#get_int to extract capture group as Integer without intermediate String https://bugs.ruby-lang.org/issues/21943 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- ## Motivation The date library is being [rewritten from C to pure Ruby](https://github.com/ruby/date/pull/155). During this effort, `Date._strptime` was identified as a major performance bottleneck. Profiling revealed that the root cause is the overhead of extracting capture groups as Strings and then converting them to Integers: ``` sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i # allocates String "2024", converts to Integer, discards String mon = sc[2].to_i # allocates String "06", converts to Integer, discards String mday = sc[3].to_i # allocates String "15", converts to Integer, discards String ``` Each `sc[n].to_i` call allocates a temporary String object that is immediately discarded. When parsing dates, only the integer values are needed — the intermediate Strings serve no purpose. In the C implementation of date, matched byte ranges are converted directly to integers without any String allocation. The pure Ruby version cannot do this with the current StringScanner API. ## Proposal Add `StringScanner#get_int(index`) that returns the captured substring at the given index as an Integer, converting directly from the matched byte range at the C level without allocating an intermediate String object. ``` scanner = StringScanner.new("2024-06-15") scanner.scan(/(\d{4})-(\d{2})-(\d{2})/) scanner.get_int(1) # => 2024 scanner.get_int(2) # => 6 scanner.get_int(3) # => 15 ``` It returns `nil` in the same cases where `scanner[index]` would return `nil` (no match, index out of range, optional group did not participate). ## Use case The primary use case is `Date._strptime` in the pure Ruby date library. The fast path for `%Y-%m-%d` format currently does: ``` # Current: 3 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc[1].to_i mon = sc[2].to_i mday = sc[3].to_i ``` With `get_int`: ``` # Proposed: 0 temporary String allocations sc.scan(/(\d{4})-(\d{2})-(\d{2})/) year = sc.get_int(1) mon = sc.get_int(2) mday = sc.get_int(3) ``` This pattern appears throughout `_strptime` for every date/time component (`%H`, `%M`, `%S`, `%m`, `%d`, etc.), so the cumulative impact is significant. ## Benchmark Environment: Ruby 4.0.1, x86_64-linux | Operation | i/s | per iteration | Comparison | | :--- | :--- | :--- | :--- | | **sc.get_int(n)** | 1,029,041.7 | 971.78 ns/i | (Reference) | | **sc[n].to_i** | 791,945.6 | 1.26 μs/i | 1.30x slower | `get_int` is 1.30x faster than `sc[n].to_i` for a typical date parsing scenario (3 capture groups). The improvement comes from eliminating 3 temporary String allocations per call. In the context of `Date._strptime("%Y-%m-%d")`, this overhead is a significant portion of the total parse time, as shown in earlier profiling: | Operation | Time | | :--- | :--- | | C ext `_strptime` (reference) | 408 ns | | SC.new + scan + captures + `.to_i` x3 | 1,210 ns | | Pure Ruby `_strptime_ymd` total | 1,290 ns | The capture extraction + `.to_i` conversion accounts for roughly 40% of the total parse time. `get_int` directly reduces this portion. ## Implementation A working implementation is available. It reuses the same index resolution logic as `StringScanner#[]` (including negative indices) but calls `rb_cstr2inum` on the matched byte range instead of `extract_range`, avoiding String object allocation entirely. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124797] [Ruby Feature#21875] Handling of trailing commas in lambda parameters
by Earlopain (Earlopain _) 06 Mar '26

06 Mar '26

Issue #21875 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #21875: Handling of trailing commas in lambda parameters https://bugs.ruby-lang.org/issues/21875 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- https://bugs.ruby-lang.org/issues/19107 was accepted, which is about trailing commands in method definitions. lambdas were not explicitly mentioned but I wanted to confirm how they should behave with a trailing comma. Or if a trailing comma should even be accepted for them. It's not clear to me since lambdas sometimes behave like blocks and sometimes more like methods. `->(...) {}` for example is syntax invalid (same as in blocks) but they do check their arity with blocks don't do. If a trailing comma is accepted it can either * be implicit splat like in `foo do |bar,|; end` or `foo do |bar|; end`. It would also mean that the trailing comma is only allowed after a positional argument. * Just be ignored and be accepted in most places like for method definitions. The first option would be rather useless in regards to https://bugs.ruby-lang.org/issues/19107 when you just want to add the comma for cleaner diffs. But I guess for lambdas this happens very rarely anyways. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124905] [Ruby Feature#21932] `MatchData#get_int`
by nobu (Nobuyoshi Nakada) 06 Mar '26

06 Mar '26

Issue #21932 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21932: `MatchData#get_int` https://bugs.ruby-lang.org/issues/21932 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- This is suggested by @akr today, `$~.get_int(1)` is equivalent to `$1.to_i` but does not create the intermediate string object. -- https://bugs.ruby-lang.org/

3 3