From: eregontp@...
Date: 2020-10-26T07:46:02+00:00
Subject: [ruby-core:100559] [Ruby master Feature#17145] Ractor-aware	`Object#deep_freeze`

Issue #17145 has been updated by Eregon (Benoit Daloze).


marcandre (Marc-Andre Lafortune) wrote in #note-31:
> My understanding is that will never be the case. You can't have 1) fast and 2) concurrent access to mutable data.

Digressing a bit, I would say it's possible ([thread-safe Array](https://eregon.me/blog/assets/research/thread-safe-collections.pdf)), but not with Ractor's model which requires copying or moving objects.
So yes, I think a mutable Array will never become Ractor-shareable because it would be too incompatible (due to copying/moveing the elements or only accepting shareable values).

Also if we have a type for which it becomes problematic, we could always add some keyword argument to handle it specially.

I think freezing all named modules and their constants could possibly be something useful for Ractor, but that IMHO should be its own method, like `Ractor.freeze_all_modules` or so. I guess in practice it doesn't work well at all, as it becomes very likely with more code, that some code needs mutable modules (e.g., @ivars on modules, `autoload` & lazy method definitions, ...).
Maybe `Ractor.freeze_all_constants` is more useful. But again with more code there is a high chance something expects a mutable constant, and that would work fine if non-main Ractors don't use it.

Anyway, they are special cases, and I think for deep freeze, it's just not interesting to freeze modules.
BTW, https://github.com/dkubb/ice_nine does not freeze modules either.
(`ruby -rice_nine -e 'IceNine.deep_freeze(Enumerable); p Object.frozen?'` => `false`)


----------------------------------------
Feature #17145: Ractor-aware `Object#deep_freeze`
https://bugs.ruby-lang.org/issues/17145#change-88188

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
----------------------------------------
I'd like to propose `Object#deep_freeze`:

Freezes recursively the contents of the receiver (by calling `deep_freeze`) and
then the receiver itself (by calling `freeze`).
Values that are shareable via `Ractor` (e.g. classes) are never frozen this way.

```ruby
# freezes recursively:
ast = [:hash, [:pair, [:str, 'hello'], [:sym, :world]]].deep_freeze
ast.dig(1, 1) # => [:str, 'hello']
ast.dig(1, 1).compact! # => FrozenError

# does not freeze classes:
[[String]].deep_freeze
String.frozen? # => false

# calls `freeze`:
class Foo
  def freeze
    build_cache!
    puts "Ready for freeze"
    super
  end
  # ...
end
[[[Foo.new]]].deep_freeze # => Outputs "Ready for freeze"
```


I think a variant `deep_freeze!` that raises an exception if the result isn't Ractor-shareable would be useful too:

```ruby
class Fire
  def freeze
    # do not call super
  end
end

x = [Fire.new]
x.deep_freeze! # => "Could not be deeply-frozen: #<Fire:0x00007ff151994748>"
```



-- 
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>