Feature #21109: Want to clarify how $/ is handled in Ractor

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

[wanabe (_ wanabe)]

I am often in trouble because $/ is inaccessible in Ractor.
For example, IO#readline can't be called from non-main Ractor.

$ echo "foo"|ruby -e 'Ractor.new do p $stdin.readline end.take'
-e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
#<Thread:0x00007efbf5ab4f58 run> terminated with exception (report_on_exception is true):
<internal:io>:133:in 'IO#readline': can not access global variables $/ from non-main Ractors (Ractor::IsolationError)
        from -e:1:in 'block in <main>'
<internal:ractor>:711:in 'Ractor#take': thrown by remote Ractor. (Ractor::RemoteError)
        from -e:1:in '<main>'
<internal:io>:133:in 'IO#readline': can not access global variables $/ from non-main Ractors (Ractor::IsolationError)
        from -e:1:in 'block in <main>'

But when I use Kernel.#readline in Ractor, the behavior is as same as main Ractor.
This behavior changes depending on whether accessing the global variable $/ in ruby or the internal rb_rs in C.

$ echo "foo"|ruby -e '$/ = "o"; Ractor.new do p readline end.take'
-e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
"fo"

I think it would be better if the behavior is unified and easy to understand.
It would be ideal if it is possible to read and write from Ractor, but even if not, it would be nice if it is at least unified to reduce confusion.

[etienne (Étienne Barrié)]

• Status changed from Open to Closed

Applied in changeset git|6ecfe643b5d8d64682c6f6bce5b27db5c007331d.

---

Freeze $/ and make it ractor safe

[Feature #21109]

By always freezing when setting the global rb_rs variable, we can ensure
it is not modified and can be accessed from a ractor.

We're also making sure it's an instance of String and does not have any
instance variables.

Of course, if $/ is changed at runtime, it may cause surprising behavior
but doing so is deprecated already anyway.

Co-authored-by: Jean Boussier [e-mail]