5 Commits

Author SHA1 Message Date
Peter Zhu
d55c463d56 Fix memory leak of Ractor basket when sending to closed Ractor
The following script leaks memory:

    r = Ractor.new { }
    r.value

    10.times do
      100_000.times do
        r.send(123)
      rescue Ractor::ClosedError
      end

      puts `ps -o rss= -p #{$$}`
    end

Before:

    18508
    25420
    32460
    40012
    47308
    54092
    61132
    68300
    75724
    83020

After:

    11432
    11432
    11432
    11432
    11432
    11432
    11432
    11432
    11432
    11688
2025-06-12 10:02:44 -04:00
Peter Zhu
89d49433a9 Fix memory leak of Ractor ports
Memory leak reported:

    3   miniruby                              0x1044b6c1c ractor_init + 164  ractor.c:460
    2   miniruby                              0x1043fd6a0 ruby_xmalloc + 44  gc.c:5188
    1   miniruby                              0x104402840 rb_gc_impl_malloc + 148  default.c:8140
    0   libsystem_malloc.dylib                0x19ab3912c _malloc_zone_malloc_instrumented_or_legacy + 152
2025-06-03 15:48:38 -04:00
Peter Zhu
7a40f1f06c Fix memory leak of Ractor recv_queue
Memory leak reported:

    3   miniruby                              0x104702c1c ractor_init + 164  ractor.c:460
    2   miniruby                              0x1046496a0 ruby_xmalloc + 44  gc.c:5188
    1   miniruby                              0x10464e840 rb_gc_impl_malloc + 148  default.c:8140
    0   libsystem_malloc.dylib                0x19ab3912c _malloc_zone_malloc_instrumented_or_legacy + 152
2025-06-03 15:48:38 -04:00
Koichi Sasada
7b75b1f2da prepare IDs for Ractor::monitor
To prevent the following strange error, prepare IDs at first.

```
     <internal:ractor>:596:in 'Ractor#monitor': symbol :exited is already registered with 98610c (fatal)
             from <internal:ractor>:550:in 'Ractor#join'
             from <internal:ractor>:574:in 'Ractor#value'
             from bootstraptest.test_ractor.rb_2013_1309.rb:12:in '<main>'
```

BTW, the error should be fixed on ID management system.
2025-05-31 18:29:02 +09:00
Koichi Sasada
ef2bb61018 Ractor::Port
* Added `Ractor::Port`
  * `Ractor::Port#receive` (support multi-threads)
  * `Rcator::Port#close`
  * `Ractor::Port#closed?`
* Added some methods
  * `Ractor#join`
  * `Ractor#value`
  * `Ractor#monitor`
  * `Ractor#unmonitor`
* Removed some methods
  * `Ractor#take`
  * `Ractor.yield`
* Change the spec
  * `Racotr.select`

You can wait for multiple sequences of messages with `Ractor::Port`.

```ruby
ports = 3.times.map{ Ractor::Port.new }
ports.map.with_index do |port, ri|
  Ractor.new port,ri do |port, ri|
    3.times{|i| port << "r#{ri}-#{i}"}
  end
end

p ports.each{|port| pp 3.times.map{port.receive}}

```

In this example, we use 3 ports, and 3 Ractors send messages to them respectively.
We can receive a series of messages from each port.

You can use `Ractor#value` to get the last value of a Ractor's block:

```ruby
result = Ractor.new do
  heavy_task()
end.value
```

You can wait for the termination of a Ractor with `Ractor#join` like this:

```ruby
Ractor.new do
  some_task()
end.join
```

`#value` and `#join` are similar to `Thread#value` and `Thread#join`.

To implement `#join`, `Ractor#monitor` (and `Ractor#unmonitor`) is introduced.

This commit changes `Ractor.select()` method.
It now only accepts ports or Ractors, and returns when a port receives a message or a Ractor terminates.

We removes `Ractor.yield` and `Ractor#take` because:
* `Ractor::Port` supports most of similar use cases in a simpler manner.
* Removing them significantly simplifies the code.

We also change the internal thread scheduler code (thread_pthread.c):
* During barrier synchronization, we keep the `ractor_sched` lock to avoid deadlocks.
  This lock is released by `rb_ractor_sched_barrier_end()`
  which is called at the end of operations that require the barrier.
* fix potential deadlock issues by checking interrupts just before setting UBF.

https://bugs.ruby-lang.org/issues/21262
2025-05-31 04:01:33 +09:00