From: eregontp@... Date: 2021-01-29T15:41:40+00:00 Subject: [ruby-core:102307] [Ruby master Feature#17592] Ractor should allowing reading shareable class instance variables Issue #17592 has been updated by Eregon (Benoit Daloze). I think 1) or 2) is much better than 0). And also this change will make it significantly easier to run existing code on Ractor, or to change the code to make it run with Ractor. I think read-write would also be fine. But read-only is definitely a good step. Concurrent `@counter += 1` would already be an issue with threads, so it doesn't seem a new issue, callers need to care if they use the previous value. For the frequent case of assigning a new shareable object, there is no problematic race there. I suspect internally, reads and writes for module ivars will need synchronization anyway, so I guess implementation-wise it's easy to allow writes. Something mentioned not so explicitly above is, of course, accessing `@ivars` of a Module in a non-main Ractor should only be allowed if the value is shareable. If the value is not shareable, then it must be `IsolationError`. ---------------------------------------- Feature #17592: Ractor should allowing reading shareable class instance variables https://bugs.ruby-lang.org/issues/17592#change-90164 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- It would be very helpful if Ractor was allowing reading class instance variables from non-main Ractor. Currently is raises an IsolationError: ```ruby module Foo singleton_class.attr_accessor :config Foo.config = {example: 42}.freeze end Ractor.new { p Foo.config } # => IsolationError ``` This limitation makes it challenging to have an efficient way to store general configs, i.e. global data that mutated a few times when resources get loaded but it immutable afterwards, and needs to be read all the time. Currently the only way to do this is to use a constant and use `remove_const` + `const_set` (which can not be made atomic easily). I think that allowing reading only may be the best solution to avoid any race condition, e.g. two different Ractors that call `@counter += 1`. The only 3 scenarios I see here are: 0) declare the constant hack the official way to store config-style data 1) allow reading of instance variables for shareable objects (as long as the data is shareable) 2) allow read-write I prefer 1) -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>