Feature #22252: improve "defined with an un-shareable Proc in a different Ractor" error

• Status: Open
• Assignee: -
• Target version: -

[getajobmike (Mike Perham)]

Hi, I'm trying to make my Ruby more compatible with Ractors. I'm seeing this error message but in an API with many abstractions, it can be difficult to determine the Proc in question. Would it be possible to include the source_location of the Proc to help improve debugging?

[getajobmike (Mike Perham)]

• Tracker changed from Bug to Feature
• ruby -v deleted (4.0.6)
• Backport deleted (3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN)

[getajobmike (Mike Perham)]

• File rtest.rb rtest.rb added

Attached is a script with the issue I ran into. define_method captures the surrounding context whereas class_eval does not.

[ufuk (Ufuk Kayserilioglu)]

Btw, if you make the block that you are passing to define_method shareable, then you can make that version work as well. The following version of the script will work properly:

# typed: true

module A
  def hello
    puts "Hello"
  end

  define_method(:hi, &Ractor.shareable_proc do |*args, **kwargs|
    puts "hi"
  end)

  class_eval(<<~RUBY, __FILE__, __LINE__ + 1)
    def ahoy(*args, **kwargs)
      puts "ahoy"
    end
  RUBY
end


class B
  include A
end

b = B.new
b.hello
b.ahoy
b.hi

r = Ractor.new do
  b2 = B.new
  b2.hello
  b2.ahoy
  b2.hi
end
r.join

[getajobmike (Mike Perham)]

Thanks for the tip. I think that points out a pretty big flaw in Ractors today -- they are incompatible with idiomatic Ruby where we pass blocks around freely. Annotating every block like this is a big scar on Ruby's elegant syntax. I wonder if a new syntax shortcut would be reasonable, for example -|> instead of & to indicate an isolate, a proc which should not capture its surroundings. I presume this has already been discussed but that's the direction I would consider.