Issue #20627 has been updated by ko1 (Koichi Sasada). I want to add new features: * `Ractor._activated` which is called when the first `Ractor.new` is called * `Ractor._require(feature)` described in this issue * `_activated` method uses `prepend` with new anonymous module to call `Ractor._require` when the `require` is called on non-main Ractors. ```ruby class Ractor class << self private # internal method def _require feature if main? super feature else Primitive.ractor_require feature end end # internal method that is called when the first "Ractor.new" is called def _activated Kernel.prepend Module.new{|m| m.set_temporary_name '<RactorRequire>' def require feature if Ractor.main? super else Ractor.__send__ :_require, feature end end } end end ``` I think most of `require` can be ractor supported. If a library uses same technique (prepend to override require), the library should call `Ractor._require` by itself. ---------------------------------------- Feature #20627: `require` on Ractor should run on the main Ractor https://bugs.ruby-lang.org/issues/20627#change-109628 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Now `require` on main Ractor is not allowed (raising error) but it is hard, especially for `autoload`. So let's allow `require` by running it on the main Ractor. ## Background On many libraries it is needed to run loading on the main Ractors because: 1. Setup constants with unshareable objects (such as `C = []`) are not allowed on non main Ractors. 2. Setup global variables and class variables are not allowed. `$LOADED_FEATURES` is also untouchable. 3. (maybe more reasons) So the `require` on non main Ractors is not allowed. However it is hard to program especially on `autoload`. Also dynamic `require` (`require` in methods) are not allowed too (`pp` method, for example). ## Proposal Allow `require` on non main Ractors by running `require` process on the main Ractor.  (quoted on my talk at RubyKaigi 2024) ### `rb_ractor_interrupt_exec(target_ractor, func)` C-API Make a thread on `target_ractor` and run `func` (C function) on it. I think it is safe to expose on Ruby API because running `func` on a *newly created* thread (do not disturb running target threads). But now it is proposed as only (hidden) C-API. ### New Ractor methods - `Ractor.main?` returns Ractors - `Ractor.require(feature)` do `require` on the main Ractor These new methods are useful for users who override `require` method like [RubyGems](https://github.com/ruby/ruby/blob/master/lib/rubygems/core_ext/kernel_requir...). ```ruby alias orig_require require def require feature return Rator.require(feature) if defined?(Ractor.main?) && !Ractor.main? # overriding require code end ``` Or we can prepend a module like: ```ruby Module.new do def require(feature) return Rator.require(feature) if defined?(Ractor.main?) && !Ractor.main? super(feature) end Kernel.prepend self end ``` will support ractors for all overgrinding methods. But not sure it is acceptable to add additional one modules in ancestors by `prepend`. Also this technique doesn't support require overriding by prepending. ## Implementation https://github.com/ruby/ruby/pull/11142 (not matured yet) ---Files-------------------------------- clipboard-202407111201-kaiem.png (70.8 KB) -- https://bugs.ruby-lang.org/