From: hunter_spawn@...
Date: 2021-01-22T16:23:30+00:00
Subject: [ruby-core:102193] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc

Issue #17543 has been updated by MaxLap (Maxime Lapointe).


Warning: The following code examples can be ugly. This is low level stuff meant to build nicer blocks on top. Viewer discretion is advised.

As codebases using Ractors grow, I expect people would want to put the logic elsewhere, in classes, and module.

Here is a very simple idea:

```
class Worker
  def initialize
    @nb_iteration = 0
  end
  
  def work(other_ractor)
    value = 123
    other_ractor.send([:use_this_block, Ractor.make_shareable(proc { |k| k << value}) ])
  
    @nb_iteration += 1
  end
end

other_ractor = Ractor.new do
  # use the block with receives...
  sleep(600)
end

w = Worker.new
10.times { w.work(other_ractor) }
```

I would expect this to work fine. The block is really just "Code I want the other side to execute". But making `self` shareable would break this.

In my mind, it's a lot more confusing that later after the call, at one point, the object raises `FrozenError (can't modify frozen Worker...)`. There won't be a helpful error message, and that call could be far away, no hints that the Ractor did it. A bit of a footgun.

And consider, if the developper needed my example to work, what would he do? I can think of many variations of "Make the self something else":

```
my_proc = Ractor.make_shareable(Object.instance_eval { -> (k) { k << value } })
other_ractor.send([:use_this_block, my_proc])
```

But now this also needs a comment, because someone seeing this will be asking questions, unless it's used everywhere (not a pretty outlook either).

It's also quite possible that the Ractor on the other side would use the block in an `instance_eval`, to change the `self`. It's a pattern that happen from time to time. In that case, the object was frozen (broken?) with no benefit.

Now, consider the alternative proposed by Marc-Andre. 

The idea of making it a special object is to avoid needing special checks during the execution of a shared block, while still allowing error messages to be helpful. The inspect could be as explicit as desired: "<This block was made shareable by Ractor, self has been detatched and is now unuseable>". It can still get confusing if the self is passed around, but as soon as you try to use it, it would fail with a `NoMethodError`. The message could even have a link to a page with details about this and ractors.

And if the person does want to go the make self sharable way, it's easy and clear:
```
Ractor.make_shareable(self)
other_ractor.send([:use_this_block, Ractor.make_shareable(proc { |k| k << value})])
```


----------------------------------------
Bug #17543: Ractor isolation broken by `self` in shareable proc
https://bugs.ruby-lang.org/issues/17543#change-90039

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: 3.0.0p0
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
Discussing with @MaxLap we realized that the `self` in a shareable proc is not properly isolated:

```
class Foo
  attr_accessor :x

  def pr
    Ractor.make_shareable(Proc.new { self })
  end
end

f = Foo.new
f.x = [1, 2, 3]
Ractor.new(f.pr) { |pr| pr.call.x << :oops }
p f.x # => [1, 2, 3, :oops]
```

If the `self` refers to a shareable object then it's fine, but for non-shareable objects it has to be reset to `nil` or to a global shareable object that would have an instructive `inspect`.

```ruby
Ractor::DETACHED_SELF = Object.new
def << Ractor::DETACHED_SELF
  def inspect
    '<#detached self>'
  end
  alias to_s inspect
end
Ractor::DETACHED_SELF.freeze
```




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