February 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:120862] [Ruby master Feature#21109] Want to clarify how $/ is handled in Ractor
by wanabe (_ wanabe) 02 Feb '25

02 Feb '25

Issue #21109 has been reported by wanabe (_ wanabe). ---------------------------------------- Feature #21109: Want to clarify how $/ is handled in Ractor https://bugs.ruby-lang.org/issues/21109 * Author: wanabe (_ wanabe) * Status: Open ---------------------------------------- I am often in trouble because `$/` is inaccessible in Ractor. For example, `IO#readline` can't be called from non-main Ractor. ``` $ echo "foo"|ruby -e 'Ractor.new do p $stdin.readline end.take' -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. #<Thread:0x00007efbf5ab4f58 run> terminated with exception (report_on_exception is true): <internal:io>:133:in 'IO#readline': can not access global variables $/ from non-main Ractors (Ractor::IsolationError) from -e:1:in 'block in <main>' <internal:ractor>:711:in 'Ractor#take': thrown by remote Ractor. (Ractor::RemoteError) from -e:1:in '<main>' <internal:io>:133:in 'IO#readline': can not access global variables $/ from non-main Ractors (Ractor::IsolationError) from -e:1:in 'block in <main>' ``` But when I use `Kernel.#readline` in Ractor, the behavior is as same as main Ractor. This behavior changes depending on whether accessing the global variable `$/` in ruby or the internal `rb_rs` in C. ``` $ echo "foo"|ruby -e '$/ = "o"; Ractor.new do p readline end.take' -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "fo" ``` I think it would be better if the behavior is unified and easy to understand. It would be ideal if it is possible to read and write from Ractor, but even if not, it would be nice if it is at least unified to reduce confusion. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120858] [Ruby master Feature#21107] Add a Ractor safety & shareability section to stdlib class docs
by osyoyu (Daisuke Aritomo) 02 Feb '25

02 Feb '25

Issue #21107 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21107: Add a Ractor safety & shareability section to stdlib class docs https://bugs.ruby-lang.org/issues/21107 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- ## Proposal Add a section describing Ractor safety and shareability for each stdlib class. For example, a description for Array could look like: ``` == Ractor safety and shareability An \Array is not Ractor shareable by default. It can be turned shareable if the following conditions are met: - The \Array itself is frozen. - All elements in the \Array are Ractor shareable as well. ``` Or, for Random: ``` == Ractor safety shareability A \Random instance cannot be made Ractor shareable. This is because of its nature having a internal state. However, Random.srand and Random.rand can be called inside Ractors. Use those if you just need a random number inside a Ractor. ``` ## Background Currently, it is not so easy to know if a object is Ractor shareable or not. While `Ractor.shareable?` exists, it is painful to test each object during programming. It does not provide information on why a object is not Ractor shareable, how it can be Ractor shareable, or if that is possible in the first place. Having this kind of information would be very helpful when writing Ractor code. It will help programmers choose more Ractor-friendly data structures and system designs. Including why the class is not Ractor-shareable could also promote efforts making the Ruby ecosystem more Ractor-compatible. ## Appendix: The SAFETY section in Rust docs The Rust language docs has a similar concept. All functions that are marked as `unsafe` are expected to have a `SAFETY` section in their documentation. The section should state why the function is unsafe, what preconditions shall be met before calling, and what can happen if those are not fulfilled. https://std-dev-guide.rust-lang.org/policy/safety-comments.html For example, documentation for std::vec::Vec.set_len states what preconditions the implementation expects, and provides examples for other safe ways. ``` Forces the length of the vector to new_len. This is a low-level operation that maintains none of the normal invariants of the type. Normally changing the length of a vector is done using one of the safe operations instead, such as truncate, resize, extend, or clear. Safety - new_len must be less than or equal to capacity(). - The elements at old_len..new_len must be initialized. ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120857] [Ruby master Bug#21106] The last iteration of the rb_ary_shuffle_bang function is useless
by usumerican (usumerican _) 01 Feb '25

01 Feb '25

Issue #21106 has been reported by usumerican (usumerican _). ---------------------------------------- Bug #21106: The last iteration of the rb_ary_shuffle_bang function is useless https://bugs.ruby-lang.org/issues/21106 * Author: usumerican (usumerican _) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-darwin21] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The number of iterations in the Fischer-Yates shuffle is (N-1) times. In the following verification code, rand function is called N times. ``` class R def rand(n) puts n return 0 end end a = [1,2,3,4,5,6,7,8,9,10] puts a.shuffle(random: R.new).join(",") ``` The while conditional expression in the rb_ary_shuffle_bang function can be changed from while(n) to while(n > 1). https://github.com/ruby/ruby/blob/db02a6b3ab4cabbdf492c26dcb1929b4ef0370a1/… -- https://bugs.ruby-lang.org/

1 0