[ruby-core:118335] [Ruby master Bug#20346] FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take

18 Jun 2024

      Issue #20346 has been updated by jpcamara (JP Camara).

Looks as though the fiber scheduler is not supported by Ractors right now, due to fixes that need to be implemented in the Ractor API. Not clear if it is expected to be fixed for 3.4 or not.

<img src="https://jpcamara.com/uploads/2024/ractor-api.jpg" width="500" height="436" alt="">

----------------------------------------
Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take
https://bugs.ruby-lang.org/issues/20346#change-108841

* Author: forthoney (Seong-Heon Jung)
* Status: Open
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
When using a `Ractor.take` inside a different thread, `Thread#join` on the thread running `Ractor.take` fails to call `FiberScheduler.unblock`. The below code can replicate this behavior
```ruby
require "async"
class RactorWrapper
  def initialize
    @ractor = Ractor.new do
      Ractor.recv # Ractor doesn't start until explicitly told to
      # Do some calculations
      fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) }
      fib.call(20)
    end
  end

  def take_async
    @ractor.send(nil)
    Thread.new { @ractor.take }.join.value
  end
end

Async do |task|
  10000.times do |i|
    task.async do
      RactorWrapper.new.take_async
      puts i
    end
  end
end
```
The above code deadlocks, and when we leave a debugging print statement inside of `Async`'s scheduler's `block` and `unblock` method, we can confirm that we only call `Scheduler.block`, and never `Scheduler.unblock`

-- 
https://bugs.ruby-lang.org/