From: daniel@...42.com Date: 2020-10-22T03:11:30+00:00 Subject: [ruby-core:100489] [Ruby master Feature#17278] On-demand sharing of constants for Ractor Issue #17278 has been updated by Dan0042 (Daniel DeLorme). ko1 (Koichi Sasada) wrote in #note-3: > * is it acceptable runtime overhead (memory + traversing)? Not so heavy, but not 0. The deep-freezing traversal has to occur at some point. Eagerly when the constant is assigned or lazily when it's accessed by a ractor; it's the same cost. But if it's lazy we ensure this cost is only incurred for the minimum possible number of objects, unlike the `shareable_constant_value` pragma. So there may be a little gain there. The FL_AUTOSHARE marking pass (#2) is indeed an extra cost, although unlike `deep_freeze` it doesn't need to call user-defined methods. So yeah, overhead would be not so heavy but not 0. > I heard there is a development rule that constants should be frozen. It's the first time I hear that, but yes it looks like [rubocop](https://www.rubydoc.info/github/bbatsov/RuboCop/RuboCop/Cop/Style/MutableConstant) has a rule like that. But not everyone uses rubocop. In my code I would consider that an anti-pattern; littering `.freeze` everywhere just _feels_ too ugly to me. > * it can delay the bug detection, if mutation is not occur frequently (it violates early bug detection) Yes, but this is the "secondary error" effect I described above. If you detect the bug early and fix it by making the constant frozen, you still have a delayed bug waiting for you if mutation doesn't occur frequently. Unless you have the discipline to search your code for modifying operations on every constant that you make frozen. > * I'm not sure all objects calls `rb_check_frozen()` before mutating their state Apart from Queue, I can't think of a case where it's ok to mutate the state of a frozen object. That would have to be a bug right? > I understand this proposal `make_sharable` lazily, until it is needed. Exactly; since you understand, would you be ok with adding this to the Developers Meeting agenda? I would like to leave this decision to you, as the Ractor developer. ---------------------------------------- Feature #17278: On-demand sharing of constants for Ractor https://bugs.ruby-lang.org/issues/17278#change-88108 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- ### Description This proposal aims to reduce (but not eliminate) the need for freezing/sharing boilerplate code needed by ractors. ```ruby A = [1, [2, [3, 4]]] H = {a: "a"} Ractor.new do p A #A is not actually modified anywhere, so ok end.take H[:b] = "b" #H was never touched by ractor, so ok ``` ## Background Ractors require objects to be preemptively deep-frozen in order to be shared between ractors. This has an especially visible and restrictive effect on globals and constants. I tried thinking of a different way, and maybe I found one. So please allow me to humbly present this possibility. ## Proposal A constant would be by default in a "auto-shareable" state (A) which can change atomically to either (B) "non-shareable" if it is modified by the main ractor (C) "shareable" (and frozen) if it is accessed by a non-main ractor In detail: 1. When an object is assigned to a constant, it is added to a list of ractor-reachable objects 2. When the first ractor is created, the objects in that list are recursively marked with FL_AUTOSHARE * after this point, constant assignments result directly in FL_AUTOSHARE 3. In the main ractor, a call to `rb_check_frozen` (meaning the object is being modified) will 1. if FL_AUTOSHARE is set (state A) * [with ractor lock] * unless object is shareable * unset FL_AUTOSHARE (state B) 2. raise error if frozen * ideally with different message if object has FL_SHAREABLE 4. When a non-main ractor accesses a non-shareable constant 1. if object referenced by constant has FL_AUTOSHARE set (state A) * [with ractor lock] * if all objects recursively are still marked with FL_AUTOSHARE * make_shareable (state C) * else * unset top objects's FL_AUTOSHARE (state B) 2. raise error if not shareable ## Result So in the case that these 2 things happen in parallel: 1) main ractor modifies content of constant X 2) non-main ractor accesses constant X There are 2 possible outcomes: a) main ractor error "can't modify frozen/shared object" b) non-main ractor error "can not access non-shareable objects in constant X" ## Benefits In the normal case where non-frozen constants are left untouched after being assigned, this allows to skip a lot of `.freeze` or `Ractor.make_shareable` or `# shareable_constant_value: true` boilerplate. When you get the error "can not access non-sharable objects in constant X by non-main Ractor", first you have to make that constant X shareable. Then this can trigger a secondary error that X is frozen, that you also have to debug. This way cuts the debugging in half by skipping directly to the FrozenError. ## Downsides When you get the error "can not access non-sharable objects in constant X by non-main Ractor" you may want to solve the issue by e.g. copying the constant X rather than freezing it. This way makes it slightly harder to find where X is being accessed in the non-main ractor. In the case of conflict, whether the error occurs in the main ractor or the non-main ractor can be non-deterministic. ## Applicability This probably applies as well to global variables, class variables, and class instance variables. -- https://bugs.ruby-lang.org/ Unsubscribe: