From: marcandre-ruby-core@... Date: 2020-12-21T14:56:43+00:00 Subject: [ruby-core:101589] [Ruby master Feature#17414] Ractor should allow access to shareable attributes for Modules/Classes Issue #17414 has been updated by marcandre (Marc-Andre Lafortune). Eregon (Benoit Daloze) wrote in #note-1: > Sounds a bit to me like a case where Thread makes more sense than Ractor I am not sure I understand your point of view. Using `yaml/psych` should be doable easily in multiple Ractors, right? Here, the config is used to register domain specific handlers. Having the global config be per-Ractor would complicate the design for no gain. I think allowing the main Ractor to change the global config, and all Ractors to read the global config seems the like the way to go. At any point in time, the global config will be an immutable data structure. After the config has changed, a different immutable data structure will be returned. ---------------------------------------- Feature #17414: Ractor should allow access to shareable attributes for Modules/Classes https://bugs.ruby-lang.org/issues/17414#change-89374 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Current situation is *very* limiting. Use-case: global config. Example: [yaml has a global config](https://github.com/ruby/psych/blob/master/lib/psych.rb#L637-L640) and it's not clear to me how to make that Ractor-aware (nicely). It is possible to have the same effect but in ugly ways: ```ruby # Using instance variables of Module not allowed: module Config class << self attr_accessor :conf end self.conf = 42 end Ractor.new { Config.conf = 66 }.take # => can not access instance variables from non-main Ractors Ractor.new { puts Config.conf }.take # => can not access instance variables from non-main Ractors # Same functionality using constants allowed: module Config class << self def conf CONF end def conf=(new_conf) remove_const(:CONF) const_set(:CONF, new_conf) end end CONF = 42 end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 # Same functionality using methods allowed: module Config class << self def conf 42 end def conf=(new_conf) singleton_class.undef_method(:conf) define_singleton_method(:conf, &Ractor.make_shareable(Proc.new { new_conf })) end end end Ractor.new { Config.conf = 66 }.take # => ok Ractor.new { puts Config.conf }.take # => 66 ``` The priority would be to allow reading these instance variables if they are shareable. Ideally writing would also be allowed, but limiting that to main ractor is less probablematic than with reading. -- https://bugs.ruby-lang.org/ Unsubscribe: