incompatible with ractors

[HoneyryderChuck]

currently, timeout can't be used in ractors:

Ractor.new do
  Timeout.timeout(4) do
    sleep(5)
  end
end.take
# .rubies/ruby-3.3.0/lib/ruby/3.3.0/timeout.rb:129:in `ensure_timeout_thread_created': can not access non-shareable objects in # # constant Timeout::TIMEOUT_THREAD_MUTEX by non-main ractor. (Ractor::IsolationError)
#         from .rubies/ruby-3.3.0/lib/ruby/3.3.0/timeout.rb:178:in `timeout'
#         from (irb):8:in `block in <top (required)>'

Lots of downstream dependencies rely on timeout, and this makes them unusable under ractors.

[eregon]

I think Thread in general is considered incompatible with Ractor (it breaks the programming model and there are several bugs with Ractor & threads), and so Timeout (which needs threads) is incompatible with Ractor.

Also: https://bugs.ruby-lang.org/issues/18139#note-2

[HoneyryderChuck]

I wouldn't go so far. If timeout would use ractor-local thread/queue/cond/mutex, it'd work. A completely alternative ractor-friendly implementation could also be an option (although I can't think of one). Was just pointing out that, the way it's implemented, it's unusable.

[jsvd]

Another point here is that the current implementation suffers in any ruby implementation that supports threading, like JRuby and TruffleRuby when using timeout for high throughput scenarios.

If multiple threads are doing very short lived timeout blocks, then the cleanup thread can easily be too slow and start accumulating Timeout.Request objects until and OOM happens.

A lot more details into this issue can be found in jruby/jruby#8406 (comment).

As it stands it's not an issue in MRI given it doesn't work in ractors, so the clean up thread is never overwhelmed.

[eregon]

@jsvd I don't consider this related, so that would be best as its own discussion or issue.

[jsvd]

@eregon fair enough, I moved the comment to a new issue #58

[eregon]

Fixed in #75 (thanks @ko1!)