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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>