[ruby-core:126673] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching

12 Sep 2026

      Issue #21869 has been updated by synacker (Mikhail Milovidov).

Thank you for the feedback, Koichi!

I’ve rebased the PR to the current master and added benchmark examples to illustrate the performance characteristics of `receive_all`. You can find the benchmarks here:

https://github.com/ruby/ruby/pull/16105/changes#diff-49ab12719789e1f00ae1d1a...

Here are the local results:

```
backlog fixnums             receive    0.04s   25637547/s   receive_all    0.02s   49357428/s   x1.93
backlog frozen strings      receive    0.06s   17879134/s   receive_all    0.05s   21309728/s   x1.19
backlog strings             receive    0.21s    4681628/s   receive_all    0.26s    3904338/s   x0.83
backlog 4 producers         receive    0.22s    4585560/s   receive_all    0.27s    3768649/s   x0.82
backlog 8 producers         receive    0.22s    4470051/s   receive_all    0.29s    3416123/s   x0.76
backlog 4 producers shared  receive    0.07s   13843510/s   receive_all    0.05s   18782983/s   x1.36
backlog 8 producers shared  receive    0.08s   12997252/s   receive_all    0.06s   16489434/s   x1.27
```

The performance degradation in some cases (e.g., strings, multiple producers) is due to GC overhead: frequent array allocations interfere with efficient GC behavior. In scenarios with shared backlogs or simpler objects (fixnums, frozen strings), `receive_all` shows a clear benefit.

----------------------------------------
Feature #21869: Add receive_all Method to Ractor API for Message Batching
https://bugs.ruby-lang.org/issues/21869#change-118970

* Author: synacker (Mikhail Milovidov)
* Status: Open
* Assignee: ractor
----------------------------------------
**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/