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

Issue #21309 has been updated by nevans (Nicholas Evans).


Eregon (Benoit Daloze) wrote in #note-6:
> 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`?

Does `Net::HTTP` use `Timeout` to implement its timeouts?  `Timeout::Error` is used as a superclass for the `net-protocol` timeout errors, but doesn't use `Timeout.timeout` directly, I think.  I'm pretty sure that `Net::HTTP` uses `Net::BufferedIO` (from `net-protocol`) for timeouts, and that switched from `Timeout.timeout` to `IO.select` in 2008, then to `wait_readable`/`wait_writable` in 2015:
* [net-protocol `rbuf_fill`] - using `read_nonblock`, `wait_readable`, and `wait_writable`
* [net-protocol `write0`]    - using `read_nonblock` and `wait_writable`
* [net-protocol `a73e9852`]  - 2018 commit adding write timeouts
* [net-protocol `23614f41`]  - 2015 commit converting read timeouts from `IO.select` to `io/wait` methods
* [net-protocol `76c28402`]  - 2008 commit converting read timeouts from `Timeout.timeout` to `IO.select`

[net-protocol `rbuf_fill`]: https://github.com/ruby/net-protocol/blob/0d0c9f372b7e571c9b446caead6af8f9386cb3ef/lib/net/protocol.rb#L216-L239
[net-protocol `write0`]: https://github.com/ruby/net-protocol/blob/0d0c9f372b7e571c9b446caead6af8f9386cb3ef/lib/net/protocol.rb#L311-L339
[net-protocol `a73e9852`]: https://github.com/ruby/net-protocol/commit/a73e9852b8dfc2384afcb2fe62eb310fc14ee586
[net-protocol `23614f41`]: https://github.com/ruby/net-protocol/commit/23614f419d98e4db1a748b16815a49bb5bf52ef6
[net-protocol `76c28402`]: https://github.com/ruby/net-protocol/commit/76c284021cec9fac23ac562eda78df113512ed47

I've been looking at adding comprehensive timeouts to `net-imap` 0.6, and considering whether or not it can be based on `BufferedIO`.

More relevant to the original purpose of _this_ ticket: [ko1's Ractor::Port ticket](https://bugs.ruby-lang.org/issues/21262) looks very promising to me, especially if it is bundled with a library of common patterns built on top of it.

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

* 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/