Bug #20978: Ractor[]/Thread[]/Fiber[] behavior difference

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 3.4.0dev (2024-12-22T06:08:19Z master 3808d29e20) +PRISM [x86_64-linux]
• Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN

[zverok (Victor Shepelev)]

Ractor.[] and .[]= support string and symbol keys (treating them by string value, and also accepting anything responding to #to_str):

Ractor[:value] = 10
Ractor[:value] #=> 10
Ractor['value'] #=> 10
o = Object.new
def o.to_str = 'value'
Ractor[o] #=> 10

Ractor[1]
# in 'Ractor.[]': 1 is not a symbol nor a string (TypeError)

But Fiber.[] only accept symbols:

Fiber[:value] = 10
Fiber['value']
# in 'Fiber.[]': wrong argument type String (expected Symbol) (TypeError)

Thread#[] and #[]= behave like Ractor’s.

(The documentation for Fiber and Thread follows the reality—while Ractor’s current docs don’t specify key type at all—but the discrepancy feels somewhat weird.)

[nobu (Nobuyoshi Nakada)]

https://github.com/ruby/ruby/pull/12438

[nobu (Nobuyoshi Nakada)]

Before d4c720a91bc7bb9ff31810e1720acffb939f7a2f, fiber storage used rb_check_id to check arguments.
This function tries to convert a non-Symbol value to a String.
So this bug is a regression, I think.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

Applied in changeset git|adad97a0310ebcd749e906be48bdabe9740deddf.

---

[Bug #20978] Stringize Fiber storage keys

[Eregon (Benoit Daloze)]

IIRC it was actually intentional to only allow symbols, as this makes it much more feasible to e.g. represent Fiber storage as object shapes.
This was discussed on the ticket adding Fiber storage.

Strings are not always interned, and interning them is a non-trivial cost.
And when not interned there is a non-trivial overhead to compare them, making every access slower.
At least the current code seems to intern (rb_to_symbol()), so using Strings is just slower but doesn't slow down every Fiber storage access.

Why would anyone want to use strings for this API, if it's going to be converted to Symbol internally anyway and so slower than using the Symbol?

[zverok (Victor Shepelev)]

Why would anyone want to use strings for this API, if it's going to be converted to Symbol internally anyway and so slower than using the Symbol?

TBH, I’d, too, rather expect only Symbols to work for such “system programming” (so to say) APIs. I just raised a concern about the inconsistency of similar APIs here.