Bug #20146: Code using Ractor with env `RUBY_MAX_CPU=1` ends with unreachable

• Status: Assigned
• Assignee: ko1 (Koichi Sasada)
• Target version: -
• ruby -v: ruby 3.4.0dev
• Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[shia (Sangyong Sim)]

Reproducible code

# sample-code.rb
Ractor.new { 1 }

RUBY_MAX_CPU=1 ruby sample-code.rb # This will not end with exit code 0
RUBY_MAX_CPU=2 ruby sample-code.rb # This ends with exit code 0 as expected

Expected

process with RUBY_MAX_CPU=1 exits successfully as same as RUBY_MAX_CPU more than 1.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to ko1 (Koichi Sasada)

[shia (Sangyong Sim)]

It seems any shared thread created when max cpu = 1 without enabled_mn_threads.

I suspect native_thread_check_and_create_shared, which always reject create shared thread.
Ref: https://github.com/ruby/ruby/blob/e4a9a73931072458f2bc13b29aeb33efb2eb9ae9/thread_pthread_mn.c#L382

As a result, scheduled Ractors won't be executed, and also won't be clean up as Ractor started.
I observed this bug fixed with this patch:

 thread_pthread_mn.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/thread_pthread_mn.c b/thread_pthread_mn.c
index c8c7d9f173..572d5e49a1 100644
--- a/thread_pthread_mn.c
+++ b/thread_pthread_mn.c
@@ -379,7 +379,8 @@ native_thread_check_and_create_shared(rb_vm_t *vm)
     rb_native_mutex_lock(&vm->ractor.sched.lock);
     {
         unsigned int snt_cnt = vm->ractor.sched.snt_cnt;
-        if (!vm->ractor.main_ractor->threads.sched.enable_mn_threads) snt_cnt++; // do not need snt for main ractor
+        // create at least one shared thread with max_cpu 1 case.
+        if (!vm->ractor.main_ractor->threads.sched.enable_mn_threads && vm->ractor.sched.max_cpu > 1) snt_cnt++;

         if (((int)snt_cnt < MINIMUM_SNT) ||
             (snt_cnt < vm->ractor.cnt  &&
--
2.25.1

(I don't think this patch is acceptable, e.g. using one more cpu for shared thread, so just explanation purpose)

Furthermore, I'm not sure expected behavior in this case.
For instance, I think here are some choices to create ractor with max cpu=1:

• always use dedicated thread as same as Thread class
• respect enable_mn_threads flag(but I think this flag might be for Thread class, not for Ractor)
• always use shared thread
  • Let max_cpu=1 be exceptional case(like above patch)
  • Let max cpu num = shared thread num to make things simpler
• prohibit max_cpu=1 mode ;)