From: hunter_spawn@hotmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:102193] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc
Date: Fri, 22 Jan 2021 16:23:30 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-90039.20210122162329.182@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17543.20210115073958.182@ruby-lang.org
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/
next prev parent reply other threads:[~2021-01-22 16:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 7:40 [ruby-core:102102] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc marcandre-ruby-core
2021-01-15 18:54 ` [ruby-core:102106] " eregontp
2021-01-16 0:55 ` [ruby-core:102110] " marcandre-ruby-core
2021-01-16 14:40 ` [ruby-core:102112] " eregontp
2021-01-16 16:41 ` [ruby-core:102114] " marcandre-ruby-core
2021-01-16 18:00 ` [ruby-core:102115] " eregontp
2021-01-16 23:45 ` [ruby-core:102117] " marcandre-ruby-core
2021-01-22 16:23 ` hunter_spawn [this message]
2021-01-22 17:17 ` [ruby-core:102195] " marcandre-ruby-core
2021-01-22 18:00 ` [ruby-core:102196] " eregontp
2021-01-29 9:19 ` [ruby-core:102294] " ko1
2021-01-29 12:31 ` [ruby-core:102300] " eregontp
2021-01-29 15:06 ` [ruby-core:102304] " marcandre-ruby-core
2023-08-24 20:34 ` [ruby-core:114510] " jeremyevans0 (Jeremy Evans) via ruby-core
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-90039.20210122162329.182@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).