Skip to content

Implement Ractor#9029

Draft
headius wants to merge 6 commits into
jruby:masterfrom
headius:ractor
Draft

Implement Ractor#9029
headius wants to merge 6 commits into
jruby:masterfrom
headius:ractor

Conversation

@headius

@headius headius commented Oct 22, 2025

Copy link
Copy Markdown
Member

Initial push is very preliminary, but can run the simple script shown below.

  • Basic construction and usage are there.
  • Port is there but it's just Queue (no shareability detection).
  • Some types aren't covered by make_shareable.
  • The given proc is checked for sanity.

Script:

foo = +"bar"
hash = {foo: foo}
ary = [hash]

puts "shareable before: #{Ractor.shareable?(ary)}"
puts "frozen at all levels?"
puts ary.frozen?
puts ary[0].frozen?
puts ary[0][:foo].frozen?

shary = Ractor.make_shareable(ary)

ractor = Ractor.new(shary) do |a|
  puts "shareable inside: #{Ractor.shareable?(a)}"
  puts "frozen at all levels?"
  puts a.frozen?
  puts a[0].frozen?
  puts a[0][:foo].frozen?
  :ok
end

puts "final value: #{ractor.value}"

* Basic construction and usage are there.
* Port is there but it's just Queue (no shareability detection).
* Some types aren't covered by make_shareable.
* The given proc is checked for sanity.
Because so many libraries change behavior upon detecting the
"Ractor" constant, a partial implementation prevents most of them
from booting properly. This moves the definition of Ractor into an
extension library, so it can be left undefined for applications
that will not use Ractors.
@headius

headius commented Oct 22, 2025

Copy link
Copy Markdown
Member Author

I've made a tweak here to move the definition of Ractor into an extension library (require 'ractor').

The current implementation is partial, but because so many libraries use the presence of the Ractor constant to change behavior, they fail to boot up and function properly. Gating the Ractor constant behind a require avoids this issue but allows me and others to continue experimenting as the API gets filled out.

I will be proposing to ruby-core that Ractor be gated behind a require there as well.

@headius

headius commented Nov 3, 2025

Copy link
Copy Markdown
Member Author

Recent change adds ractor as a feature that can be enabled or disabled (default disabled for now). This breaks a spec that expects all features to be either enabled or disabled by --all or omission of that flag.

There's also an alternative implementation in pure Ruby on top of Thread and Queue here that could be shipped as our implementation of Ractor. Since the work here has primarily been to get make_shareable working and my implementation of Ractor and Port largely just use Thread and Queue, this would be a logical move (a shared implementation for all non-CRuby impls that already have parallel threads). cc @eregon

* Use an enum for features and their enablers and aliases.
* Avoid confusing "disabled" booleans by using "enabled" booleans.
* Deprecate old accessors.
* Add missing accessors for error_highlight feature.
@eregon

eregon commented Nov 3, 2025

Copy link
Copy Markdown
Contributor

There's also an alternative implementation in pure Ruby on top of Thread and Queue here that could be shipped as our implementation of Ractor.

Right, that's https://github.com/eregon/ractor-shim and it implements all methods of the Ruby 4.0 Ractor API.

@headius

headius commented Mar 4, 2026

Copy link
Copy Markdown
Member Author

Land this or ship the shim library in 10.1. We need to have Ractor.make_shareable available, since projects are already moving to use it (see dry-rb/dry-struct#203 for example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants