From: marcandre-ruby-core@... Date: 2020-12-02T17:42:32+00:00 Subject: [ruby-core:101206] [Ruby master Bug#17359] Ractor copy mode is not Ractor-safe Issue #17359 has been updated by marcandre (Marc-Andre Lafortune). Dan0042 (Daniel DeLorme) wrote in #note-14: > I think it's feasible. `initialize_clone` and `initialize_copy` are mostly (only?) used because `clone` and `dup` only Indeed, I imagine that this will be most of the cases, as of today (i.e. before Ractor). My concern is to have some way for user classes to handle special cases of deep-cloning for Ractor, in the same way that calling `freeze` from `Ractor.make_shareable` provides a basic way to handle deep-freezing. Without one, and without `Ractor::LVar`, there would be no way to handle these special cases. Or maybe we can begin without it and we can revisit as use-cases arise, I don't know. ---------------------------------------- Bug #17359: Ractor copy mode is not Ractor-safe https://bugs.ruby-lang.org/issues/17359#change-88890 * Author: marcandre (Marc-Andre Lafortune) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0dev (2020-11-30T10:06:25Z master 89774a938a) [x86_64-darwin18] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- It should not be possible to mutate an object across Ractors, but the copy mode allows it currently: ```ruby class Foo attr_accessor :x def initialize_copy(*) $last = self super end end o = Foo.new o.x = 42 r = Ractor.new(o) do |copy| puts copy.x # => 42 Ractor.yield :sync Ractor.yield :sync puts copy.x # => 666 end r.take # => :sync $last.x = 666 r.take # => :sync r.take ``` Maybe the `copy` object should be marked as moved? -- https://bugs.ruby-lang.org/ Unsubscribe: