Feature #18127: Ractor-local version of Singleton

• Status: Closed
• Assignee: -
• Target version: -

[rm155 (Rohit Menon)]

Background
When the Singleton module (from the Singleton library) is included in a class, that class will have only one instance. Since the instance can only be in one Ractor at once, Singleton is not Ractor-compatible. For example, the following code would fail upon trying to access Example.instance in the Ractor:

class Example
  def initialize
    @value = 1
  end
end
Example.include Singleton

Ractor.new do
  Example.instance
end.take
#=> can not access instance variables of classes/modules from non-main Ractors (Ractor::IsolationError)

In some cases, this may be the desired behavior, as it may be important that the class truly have only one instance. However, in many other cases, it would be more convenient for the class to have one instance per Ractor.

Proposal
The proposal is to create a RactorLocalSingleton module that can be included instead of Singleton to make the instance Ractor-local.
Here is how RactorLocalSingleton might be used in the situation above:

class Example
  def initialize
    @value = 1
  end
end
Example.include RactorLocalSingleton

Ractor.new do
  Example.instance
end.take

Discussion
The advantage of creating RactorLocalSingleton is that classes could have Singleton-like behavior while being usable in Ractors. Since some libraries, such as Prime, currently rely on the Singleton module, this would enable those libraries to have more flexibility with Ractors.
The disadvantage of creating this module is that it supports the continued use of the Singleton design pattern, which is sometimes considered harmful. An alternative to RactorLocalSingleton might be to simply use Thread-local variables as Singleton instances. Here is how Thread-local variables might be used in the given situation:

class Example
  def initialize
    @value = 1
  end
end

Ractor.new do
  Thread.current[:Example] = Example.new
  Thread.current[:Example]
end.take

Summary
Classes that include Singleton are currently incompatible with Ractors. By instead including a new module RactorLocalSingleton, classes can have Singleton-like properties while being used in Ractors. However, this may perpetuate the use of the Singleton design pattern, and using Thread-local variables may be a preferable solution.

[ko1 (Koichi Sasada)]

code: https://github.com/ruby/singleton/pull/4/files

[ko1 (Koichi Sasada)]

The advantage of this RactorLocalSingleton is, if a library uses singleton library and it is okay to make an instance per Ractor (memo-usage, for example), it is easy to support ractors.

[matz (Yukihiro Matsumoto)]

OK, accepted.

Matz.

[ioquatix (Samuel Williams)]

I appreciate the work that is being done here. However I am against introducing this feature as currently proposed and think that more discussion is required.

This change does not address the fact that Singleton remains broken when used with Ractor. Users should not need to care whether Ractor is used or not. A better solution is to fix Singleton so that it's Ractor compatible. This seems like leaky abstraction.

@matz (Yukihiro Matsumoto) are you happy with Ractor-specific interfaces spreading across Ruby code? especially given that other implementations of Ruby don't necessarily support it?

1. Existing Ruby code is incompatible with Ractor.
2. New code that is compatible with Ractor is incompatible with old versions of CRuby and other implementations e.g. TruffleRuby and JRuby.

Based on this and other issues exposing Ractor specific code paths, I'm concerned too much of the implementation detail is leaking into public interfaces and introduces many new complexities into user code.

[Dan0042 (Daniel DeLorme)]

ioquatix (Samuel Williams) wrote in #note-4:

1. Existing Ruby code is incompatible with Ractor.
2. New code that is compatible with Ractor is incompatible with old versions of CRuby and other implementations e.g. TruffleRuby and JRuby.

Based on this and other issues exposing Ractor specific code paths, I'm concerned too much of the implementation detail is leaking into public interfaces and introduces many new complexities into user code.

That's a really good summary of the current situation with Ractor. Too many things need to be modified, frozen, restricted, even for code that doesn't use Ractor, just in case some code wants to use Ractor. That's because Ractor is fundamentally incompatible with mutable global objects. That's part of its design, and I think that's a good design. But it does mean that Ractor-compatible code must use different patterns. Rather than freezing all global state, IMHO in the Ractor design it's more appropriate to use local state only. Global config should be passed to the Ractor as an argument, etc.

So going back to the topic of Singleton, it's fundamentally incompatible with Ractor if mutable. There are two possible solutions: 1) make the singleton immutable, 2) use one "singleton" per Ractor. I don't think it's possible to pick one of these as default, which means we can't "fix Singleton so that it's Ractor compatible".

• For solution 1, instead of Ractor.make_shareable it would be nice to combine Singleton with the Immutable module suggested in #18035 in order to create a frozen singleton.
• For solution 2... if there's one singleton per Ractor then it's not actually a singleton at all. We just limit to one instance for efficiency. Instead of RactorLocalSingleton why not create an instance when needed? Ractor.new{ example = Example.new } or Thread-local variables as ko1 mentioned.

In each case, there's a solution that doesn't "leak" the Ractor concept everywhere into unrelated code.

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Closed

I have been merged https://github.com/ruby/singleton/pull/4