[ruby-core:121909] [Ruby Feature#21309] Can Thread::Mutex be Ractor shareable?

Issue #21309 has been updated by Eregon (Benoit Daloze).

Status changed from Open to Rejected

osyoyu (Daisuke Aritomo) wrote in #note-5:
> I am not sure about this. Sending HTTP request using net/http inside an Ractor should be a valid use case, and `Timeout` is blocking this (it is internally used to implement `open_timeout` `read_timeout` and `write_timeout`.

Ideally Net::HTTP wouldn't use Timeout (which is for interrupting code using too much CPU), interrupting I/O in general should be done without Timeout (because Timeout is too heavy for that).
Maybe Net::HTTP could use `IO.select`?

> am okay to close this ticket

I'll close it then

----------------------------------------
Feature #21309: Can Thread::Mutex be Ractor shareable?
https://bugs.ruby-lang.org/issues/21309#change-112978

* Author: osyoyu (Daisuke Aritomo)
* Status: Rejected
----------------------------------------
## Background

Keeping a `Mutex` object in a constant or a class instance variable is a common pattern seen in code with thread safety in mind. However, this kind of code does not play well with Ractors:

```ruby
require 'thread'

class C
  MUTEX = Mutex.new

  def self.foo
    MUTEX.synchronize { p 1 }
  end
end

Ractor.new {
  C.foo
}.take
```

```
t.rb:11: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
#<Thread:0x000000011d80f368 run> terminated with exception (report_on_exception is true):
t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError)
        from t.rb:12:in 'block in <main>'
<internal:ractor>:711:in 'Ractor#take': thrown by remote Ractor. (Ractor::RemoteError)
        from t.rb:13:in '<main>'
t.rb:7:in 'C.foo': can not access non-shareable objects in constant C::MUTEX by non-main ractor. (Ractor::IsolationError)
        from t.rb:12:in 'block in <main>'
```

Many libraries follow this pattern. `Mutex` not being Ractor shareable is blocking these libraries from being used from inside Ractors.
`Timeout` in stdlib in particular has large impact since it is required from many other gems by default, including `net/http`.

https://github.com/ruby/timeout/blob/v0.4.3/lib/timeout.rb#L49-L50
https://github.com/lostisland/faraday/blob/v2.13.1/lib/faraday/middleware.rb#L13

## Proposal

Make built-in concurrency primitives (Thread::Mutex, Thread::ConditionVariable and Thread::Queue) Ractor shareable.

While this idea may not be strictly aligned with idea of the Ractor world (exchanging messages for controlling concurrency?), I have the feeling that too many code is blocked from running in Ractors because `Mutex` is not Ractor shareable.
Allowing `Mutex`es to be shared would make a large portion of existing Ruby code Ractor-compatible, or at least make migration much easier.
I believe that it won't be semantically incorrect, since they are concurrency primitives after all.

One thing to consider that the current `Mutex` implementation is based on the GVL (I believe so). Migration to some other implementation e.g. pthread_mutex or CRITICAL_SECTION may be needed to make Mutex work well on Ractors.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/