< :前の番号
^ :番号順リスト
> :次の番号
P :前の記事(スレッド移動)
N :次の記事(スレッド移動)
|<:前のスレッド
>|:次のスレッド
^ :返事先
_:自分への返事
>:同じ返事先を持つ記事(前)
<:同じ返事先を持つ記事(後)
---:分割してスレッド表示、再表示
| :分割して(縦)スレッド表示、再表示
~ :スレッドのフレーム消去
.:インデックス
..:インデックスのインデックス
Issue #18243 has been updated by Eregon (Benoit Daloze).
Dan0042 (Daniel DeLorme) wrote in #note-7:
> It's not uncommon for a proc to have behavior that is independent of `self`.
Yes, but it's not so trivial to assert it is the case for any non-trivial block/Proc.
Changing the self is breaking the context in which it was written, and I think that should be avoided in most cases.
`define_method(name) { ... }` is clear that the self is not the surrounding self, but that's about the only core method with those semantics and it needs to be like that of course.
> From the posts by @eregon it was unclear to me if "self must be shareable" was intended only for an explicit reference to `self`.
All Proc capture `self`, there is no other way currently.
I think we need `define_method(name, make_shareable: true) { ... }` (name up for discussion) and there we know it does not matter what the surrounding `self` is.
`Ractor.make_shareable(some_proc)` must make `some_proc` and all objects reachable from it shareable, hence the `self` captured by the Proc must be shareable, or it breaks the entire concept of Ractor isolation and shareable.
So either it does `Ractor.make_shareable(proc_self)` or it raises an exception.
Changing the proc's `self` on `make_shareable` seems way too confusing, I don't even consider it a reasonable possibility.
----------------------------------------
Bug #18243: Ractor.make_shareable does not freeze the receiver of a Proc but allows accessing ivars of it
https://bugs.ruby-lang.org/issues/18243#change-94433
* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
```ruby
class C
attr_accessor :foo
def setter_proc
Ractor.make_shareable(-> v { @foo = v })
end
end
c = C.new
c.foo = 1
p c
proc = c.setter_proc
p c.frozen?
Ractor.new(proc) { |s| s.call(42) }.take
p c
```
gives
```
#<C:0x00007f2a3aae7a98 @foo=1>
false
#<C:0x00007f2a3aae7a98 @foo=42> # BUG
```
But that must be a bug, it means the non-main Ractor can directly mutate an object from the main Ractor.
I found this while thinking about https://github.com/ruby/ostruct/pull/29/files and
whether `Ractor.make_shareable` would freeze `@table` and the `OpenStruct` instance (I think it needs to).
Repro code for ostruct and changing ostruct.rb to `$setter = ::Ractor.make_shareable(setter_proc)`:
```ruby
require 'ostruct'
os = OpenStruct.new
os.foo = 1
$setter.call(2)
p os
Ractor.new($setter) { |s| s.call(42) }.take
p os
```
gives
```
#<OpenStruct foo=2>
<internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
#<OpenStruct foo=42> # BUG
```
--
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>