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/

Issue #20346 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed This no longer deadlocks. Under the new Ractor API the `take` should be replaced with `value`. ``` 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.value }.value end end Async do |task| 10000.times do |i| task.async do RactorWrapper.new.take_async puts i end end end ``` I recorded a profile showing that the concurrency is happening properly (warning: this has 10k threads of data) https://share.firefox.dev/4lCxnFK ---------------------------------------- Bug #20346: FiberScheduler.unblock not called by Thread#join when Thread body contains Ractor.take https://bugs.ruby-lang.org/issues/20346#change-114346 * Author: forthoney (Seong-Heon Jung) * Status: Closed * Assignee: ractor * 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/