Timeout::ExitException can be raised by nested timeouts

Behavior

Nested timeout blocks can result in a Timeout::ExitException being raised, rather than a Timeout::Error

How to reproduce

The below will sometimes raise a Timeout::ExitException, sometimes a Timeout::Error (roughly 50/50).
  

begin
  Timeout.timeout(2) do
    Timeout.timeout(2) do
      sleep 3
    end
  end
rescue Exception => e
  puts "raised a #{e.class}"
end

Cause (maybe)

Hacking up the Timeout module as follows:

module Timeout
  class Error
    def self.handle_timeout(message) # :nodoc:
      exc = ExitException.new(message)

      begin
        puts "yield #{exc.object_id} (#{message})"
        yield exc
      rescue ExitException => e
        puts "test #{e.object_id} vs #{exc.object_id} => #{exc.equal?(e)} (#{message})"
        raise new(message) if exc.equal?(e)
        puts "re-raise #{e.object_id}('#{e}') (#{message})"
        raise
      end
    end
  end
end

Timeout.timeout(2, nil, "outer timeout") do
  Timeout.timeout(2, nil, "inner timeout") do
    sleep 3
  end
end

shows that, when an ExitException is raised, the "inner" exception is being caught by the "outer" handle_timeout block. Suspicious this is the result of indeterminate Thread#raise behavior?

Environment

Ruby 3.3.5
Timeout 0.4.1
Ubuntu 24.04.1 running on WSL2

Inizia eseguendo il riproduttore di Timeout.timeout annidato dell’issue e ispeziona il percorso di Timeout.timeout, in particolare Timeout::Error.handle_timeout e la gestione di ExitException. Conferma le condizioni che permettono all’eccezione interna di raggiungere l’handler esterno; il lavoro è concluso quando i timeout annidati sollevano sistematicamente Timeout::Error invece di Timeout::ExitException, con un controllo di regressione per il riproduttore.