From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "Eregon (Benoit Daloze)" <noreply@ruby-lang.org>
Subject: [ruby-core:111833] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors
Date: Mon, 16 Jan 2023 13:41:56 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-101242.20230116134155.1241@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-19154.20221126235222.1241@ruby-lang.org
Issue #19154 has been updated by Eregon (Benoit Daloze).
luke-gru (Luke Gruber) wrote in #note-2:
> As long as there's a mutex somewhere protecting these mutations it's safe. There is a mutex around rubygems require. I only had to add `Ractor.force_shareable!` to 2 or 3 places in the rubygems code and requiring gems now works across Ractors. I didn't add any tests but I might add some if other people are interested in this work.
That's completely unsafe. You can look at the implementation of Mutex and you can see it relies on the GVL. With Ractors there is not a single GVL, so simply said Mutex (and Monitor too) does not prevent concurrent access with Ractors.
That's one big reason why one cannot share a Mutex/Monitor.
Also sharing a Mutex/Monitor would be a clear violation of the Ractor programming model.
I think `require`/`autoload` in a Ractor should simply be forbidden (raise an exception), see #17420.
It cannot work since it needs access to $LOADED_FEATURES, and that's owned by the main Ractor and is unsafe to access for any other Ractor.
----------------------------------------
Bug #19154: Specify require and autoload guarantees in ractors
https://bugs.ruby-lang.org/issues/19154#change-101242
* Author: fxn (Xavier Noria)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
Given a file `c.rb`:
```ruby
class C
end
```
the following script:
```ruby
r1 = Ractor.new do
require './c.rb'
end
r2 = Ractor.new do
require './c.rb'
end
r1.take
r2.take
```
raises:
```
% ruby -v foo.rb
ruby 3.2.0preview3 (2022-11-27) [x86_64-darwin22]
foo.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
#<Thread:0x000000010fee2928 run> terminated with exception (report_on_exception is true):
#<Thread:0x00000001102acfe0 run> terminated with exception (report_on_exception is true):
<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError)
from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require'
from foo.rb:6:in `block in <main>'
<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require'<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError)
from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require'
can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from foo.rb:2:in `block in <main>'
<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError)
from foo.rb:2:in `block in <main>'
from foo.rb:6:in `block in <main>'
<internal:ractor>:698:in `take': thrown by remote Ractor. (Ractor::RemoteError)
from foo.rb:9:in `<main>'
<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError)
from <internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:167:in `require'
from foo.rb:2:in `block in <main>'
<internal:/Users/fxn/.rbenv/versions/3.2.0-preview3/lib/ruby/3.2.0+3/rubygems/core_ext/kernel_require.rb>:37:in `require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError)
from foo.rb:2:in `block in <main>'
```
Would it be possible to have documentation about their interaction?
This is important also to understand autoloading within ractors, since constant references may trigger `require` calls.
--
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/postorius/lists/ruby-core.ml.ruby-lang.org/
next prev parent reply other threads:[~2023-01-16 13:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-26 23:52 [ruby-core:111027] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors fxn (Xavier Noria)
2022-11-27 0:01 ` [ruby-core:111028] " fxn (Xavier Noria)
2022-12-01 13:00 ` [ruby-core:111128] " alanpowel47 (Alan Powel)
2023-01-15 1:33 ` [ruby-core:111814] " luke-gru (Luke Gruber) via ruby-core
2023-01-15 7:54 ` [ruby-core:111817] " luke-gru (Luke Gruber) via ruby-core
2023-01-16 13:41 ` Eregon (Benoit Daloze) via ruby-core [this message]
2023-01-16 13:59 ` [ruby-core:111835] " fxn (Xavier Noria) via ruby-core
2023-01-16 19:46 ` [ruby-core:111841] " Eregon (Benoit Daloze) via ruby-core
2023-01-31 16:20 ` [ruby-core:112141] " luke-gru (Luke Gruber) via ruby-core
2023-01-31 17:02 ` [ruby-core:112145] " fxn (Xavier Noria) 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-101242.20230116134155.1241@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
--cc=noreply@ruby-lang.org \
--cc=ruby-core@ml.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).