[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116059] [Ruby master Bug#20146] Code using Ractor with env `RUBY_MAX_CPU=1` ends with unreachable
From:
"shia (Sangyong Sim) via ruby-core" <ruby-core@...>
Date:
2024-01-07 01:28:43 UTC
List:
ruby-core #116059
Issue #20146 has been updated by 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:
```diff
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, which actually use 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 ;)
----------------------------------------
Bug #20146: Code using Ractor with env `RUBY_MAX_CPU=1` ends with unreachable
https://bugs.ruby-lang.org/issues/20146#change-106057
* Author: shia (Sangyong Sim)
* Status: Assigned
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 3.4.0dev
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
## Reproducible code
```rb
# sample-code.rb
Ractor.new { 1 }
```
```bash
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.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/