Bug #17506: Ractor isolation broken by ThreadGroup

• Status: Closed
• Assignee: ractor
• Target version: -
• ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin18]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN

[marcandre (Marc-Andre Lafortune)]

Ractors currently share the ThreadGroup.

This doesn't seem very useful as there is no possible communication between the Threads of different Ractors.

It is also an isolation error:

ThreadGroup.attr_accessor :foo
var = Thread.current.group.foo = [:example]
Ractor.new { Thread.current.group.foo << [:oops] }.take
var # => [:example, [:oops]]

Should Ractor.new create a new ThreadGroup? Should ThreadGroup not have (non-shareable) instance variables? Or should Ractor.new { Thread.current.group }.take be nil? See also https://bugs.ruby-lang.org/issues/17505 about nil.

Note that Ractor respects the ThreadGroup's state:

Thread.current.group.enclose
Ractor.new { Thread.current.group.add(Thread.current) }.take # => can't move to the enclosed thread group

Thread.current.group.freeze
Ractor.new {} # => ThreadError (can't start a new thread (frozen ThreadGroup))

I am not sure what is the best behavior as I don't have enough experience with how ThreadGroups are used, especially enclosed ThreadGroups.

[byroot (Jean Boussier)]

• Assignee set to ractor

Retested on 3.4.2, and it seems the bug is still present.

[byroot (Jean Boussier)]

• Status changed from Open to Closed

Applied in changeset git|5e421ce8d949a4f92568db359be0d188b66e58ca.

---

ractor: don't inherit the default thread group

[Bug #17506]

Thread.current.group isn't shareable so it shouldn't be inherited
by the main thread of a new Ractor.

This cause an extra allocation when spawning a ractor, which could
be elided with a bit of extra work, but not sure if it's worth
the effort.