Skip to content

Conversation

@headius
Copy link
Member

@headius headius commented Oct 22, 2025

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
Copy link
Member Author

headius commented Oct 22, 2025

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
Copy link
Member Author

headius commented Nov 3, 2025

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
Copy link
Member

eregon commented Nov 3, 2025

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 3.5 Ractor API.

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