From: "Eregon (Benoit Daloze) via ruby-core" Date: 2023-01-16T13:41:56+00:00 Subject: [ruby-core:111833] [Ruby master Bug#19154] Specify require and autoload guarantees in ractors 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. # terminated with exception (report_on_exception is true): # terminated with exception (report_on_exception is true): :164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from :167:in `require' from foo.rb:6:in `block in
' :37:in `require':164:in `ensure in require': : can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from :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
' :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
' from foo.rb:6:in `block in
' :698:in `take': thrown by remote Ractor. (Ractor::RemoteError) from foo.rb:9:in `
' :164:in `ensure in require': can not access non-shareable objects in constant Kernel::RUBYGEMS_ACTIVATION_MONITOR by non-main ractor. (Ractor::IsolationError) from :167:in `require' from foo.rb:2:in `block in
' :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
' ``` 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/