Feature #21039: Ractor.make_shareable breaks block semantics (seeing updated captured variables) of existing blocks

• Status: Assigned
• Assignee: ko1 (Koichi Sasada)
• Target version: -

[Eregon (Benoit Daloze)]

def make_counter
  count = 0
  nil.instance_exec do
    [-> { count }, -> { count += 1 }]
  end
end

get, increment = make_counter

reader = Thread.new {
  sleep 0.01
  loop do
    p get.call
    sleep 0.1
  end
}

writer = Thread.new {
  loop do
    increment.call
    sleep 0.1
  end
}

ractor_thread = Thread.new {
  sleep 1
  Ractor.make_shareable(get)
}

sleep 2

This prints:

1
2
3
4
5
6
7
8
9
10
10
10
10
10
10
10
10
10
10
10

But it should print 1..20, and indeed it does when commenting out the Ractor.make_shareable(get).

This shows a given block/Proc instance is concurrently broken by Ractor.make_shareable, IOW Ractor is breaking fundamental Ruby semantics of blocks and their captured/outer variables or "environment".

It's expected that Ractor.make_shareable can freeze objects and that may cause some FrozenError, but here it's not a FrozenError, it's wrong/stale values being read.

I think what should happen instead is that Ractor.make_shareable should create a new Proc and mutate that.
However, if the Proc is inside some other object and not just directly the argument, that wouldn't work (like Ractor.make_shareable([get])).

So I think one fix would to be to only accept Procs for Ractor.make_shareable(obj, copy: true).
FWIW that currently doesn't allow Procs, it gives <internal:ractor>:828:in 'Ractor.make_shareable': allocator undefined for Proc (TypeError).
It makes sense to use copy here since make_shareable effectively takes a copy/snapshot of the Proc's environment.

I think the only other way, and I think it would be a far better way would be to not support making Procs shareable with Ractor.make_shareable.
Instead it could be some new method like isolated { ... } or Proc.isolated { ... } or Proc.snapshot_outer_variables { ... } or so, only accepting a literal block (to avoid mutating/breaking an existing block), and that would snapshot outer variables (or require no outer variables like Ractor.new's block, or maybe even do Ractor.make_shareable(copy: true) on outer variables) and possibly also set self since that's anyway needed.
That would make such blocks with different semantics explicit, which would fix the problem of breaking the intention of who wrote that block and whoever read that code, expecting normal Ruby block semantics, which includes seeing updated outer variables.
Related: #21033 https://bugs.ruby-lang.org/issues/18243#note-5

Extracted from https://bugs.ruby-lang.org/issues/21033#note-14

[Eregon (Benoit Daloze)]

• ruby -v set to ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux]

[Eregon (Benoit Daloze)]

• Related to Bug #18243: Ractor.make_shareable does not freeze the receiver of a Proc but allows accessing ivars of it added

[Eregon (Benoit Daloze)]

• Related to Feature #21033: Allow lambdas that don't access `self` to be Ractor shareable added

[Eregon (Benoit Daloze)]

• Description updated (diff)

[Eregon (Benoit Daloze)]

• Description updated (diff)

[luke-gru (Luke Gruber)]

As far as I know this is intentional behavior, so even though I agree it is confusing I think this is more accurately a feature request instead of a bug.

[Eregon (Benoit Daloze)]

I think it's a bug, because it breaks fundamental Ruby block semantics.
No Ractor method or functionality should be able to do that for an existing Proc, even more so when that Proc is called on the main Ractor.

[luke-gru (Luke Gruber)]

Okay fair enough, and it's not of much consequence either way whether it's a bug or a feature because your point still stands.

[matz (Yukihiro Matsumoto)]

• Tracker changed from Bug to Feature
• ruby -v deleted (ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [x86_64-linux])
• Backport deleted (3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN)

1. It's intended behavior. We don't call it a bug. If we keep the non-shareable semantics, the basic principle of Ractors would fail (no shared state).
2. I understand your feeling to the new behavior. The behavior can be negotiable, but it should follow Ractor principle.

Matz.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned

[Eregon (Benoit Daloze)]

I think a good solution here would be:

• raise on Ractor.make_shareable(proc)
• raise on Ractor.make_shareable(proc, copy: true)
• allow Ractor.make_shareable { ... } but only with a block literal. That way, the fact that block behaves differently by copying its environment is very clear. The method could check that the block doesn't do assignments in the environment as well to avoid surprises. It could also set the self in the block to nil, and/or take a keyword argument to set the receiver, or use the block's original self and error if it cannot be made shareable.

[matz (Yukihiro Matsumoto)]

I'd like to have Ractor.shareble_proc and Ractor.sharable_lambda. See the agenda from 20250710 developer meeting.

Matz.

[mame (Yusuke Endoh)]

https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeeting-2025-07-10.md#feature-21039-ractormake_shareable-breaks-block-semantics-seeing-updated-captured-variables-of-existing-blocks-eregon

• Ractor.shareable_proc { } returns a Proc that is shareable between ractors. In the proc, self is nil.
• Ractor.shareable_proc(self: 42) { } returns a Proc that is shareable between ractors. In the proc, self is 42.
• Ractor.shareable_lambda returns a lambda-version of Ractor.shareable_proc.

[mame (Yusuke Endoh)]

The followings are also approved; changing an existing proc object to shareable should be prohibited.

• raise on Ractor.make_shareable(proc)
• raise on Ractor.make_shareable(proc, copy: true)

[Eregon (Benoit Daloze)]

Great to hear, this makes a lot of sense and addresses the original semantics issue perfectly.