From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2025-01-14T19:52:35+00:00
Subject: [ruby-core:120670] [Ruby master Feature#21033] Allow lambdas that don't access `self` to be Ractor shareable

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


I played with `Ractor.make_shareable` and it already mutates a Proc in place, breaking the basic Ruby semantics of re-assigning variables captured by blocks:
```ruby
a = 1

l = nil.instance_exec {
  -> {
    a
  }
}

Ractor.make_shareable(l)
a = Object.new
p l.call # => with make_shareable above: 1, without: #<Object:0x00007f357d828020>

r = Ractor.new {
  p Ractor.receive.call # => 1, ignoring that `a = Object.new` assignment above, i.e. breaking Ruby block semantics
}

r.send(l)
r.take
```
Given semantics are already incompatible when using `Ractor.make_shareable`, maybe that should change the receiver to `nil` too?
It doesn't feel right (IMO it's broken semantics) but since it's already incompatible with normal Ruby semantics, might as well make it useful?
Is changing self worse than preventing to see captured variables updates? (I don't know)
WDYT @ko1?

I think a proper solution would be a way to declare an isolated block (to be precise, using `nil` as `self`; and either allowing no captured variables like `Ractor.new`'s block or only allowing shareable captured variables and taking a snapshot of them i.e. not seeing updates), either with a new method or new syntax (which could then do the captured variables checks at parse time for the no captures variant).
Then it's fair for those to have different semantics, vs mutating existing Ruby blocks to have different semantics if `Ractor.make_shareable` has ever been called on them.

----------------------------------------
Feature #21033: Allow lambdas that don't access `self` to be Ractor shareable
https://bugs.ruby-lang.org/issues/21033#change-111495

* Author: tenderlovemaking (Aaron Patterson)
* Status: Open
----------------------------------------
Hi,

I would like to allow lambdas that don't access `self` to be eligible for Ractor shareability regardless of the shareability status of `self`.

Consider the following code:

```ruby
class Foo
  def make_lambda
    x = 123
    lambda { x }
  end
end

Ractor.make_shareable(Foo.new.make_lambda)
```

With Ruby 3.4.X, this will raise an exception.  The reason is because `self`, which is an unfrozen instance of `Foo`, is not shareable.  However, we can see from the code that the lambda doesn't access `self`.  I would like to make lambdas such as the ones above eligible for shareability, and I've submitted a patch [here](https://github.com/ruby/ruby/pull/12567).

I think we can detect access to `self` by scanning the instructions in the lambda.  Any references to `putself`, `getinstancevariable`, or `setinstancevariable` will result in using the default behavior (checking the frozen status of `self`).

## Considerations

### What about `eval`?

I think that `eval` is not a problem because calling eval has an implicit reference to `self`:

```
$ ./miniruby --dump=insns -e 'lambda { eval("123") }'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,22)>
0000 putself                                                          (   1)[Li]
0001 send                                   <calldata!mid:lambda, argc:0, FCALL>, block in <main>
0004 leave

== disasm: #<ISeq:block in <main>@-e:1 (1,7)-(1,22)>
0000 putself                                                          (   1)[LiBc]
0001 putchilledstring                       "123"
0003 opt_send_without_block                 <calldata!mid:eval, argc:1, FCALL|ARGS_SIMPLE>
0005 leave                                  [Br]
```

If we try to call `eval` inside the lambda, there will be an implicit `putself` instruction added which means we will fall back to the old behavior.

### What about `binding`?

If you call `binding` from inside the `lambda` there will be a `putself` instruction so we fall back to the old behavior.  This is the same as the `eval` case.

### What about `binding` via a local?

If you assign `binding` to a local, shareability will fail because the `lambda` references an unshareable local:

```ruby
class Foo
  def make_lambda
    x = binding
    lambda { x }
  end
end

b = Foo.new.make_lambda
# exception because local `x` is not shareable
Ractor.make_shareable(b)
```

### What about accessing `binding` via the proc itself?

The lambda can references itself via a local and access binding, but again this will fail isolation when locals are scanned:

```ruby
class Foo
  def make_lambda
    x = lambda { x.binding.eval("self") }
  end
end

b = Foo.new.make_lambda
# exception because local `x` is not shareable
Ractor.make_shareable(b)
```

I _think_ I've covered all cases where `self` can possibly escape.  I would appreciate any feedback.

Again, [here is the patch](https://github.com/ruby/ruby/pull/12567).

Thanks.

---Files--------------------------------
0001-Allow-lambdas-that-don-t-access-self-to-be-made-shar.patch (6.51 KB)


-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/