2015-12-16 08:07:31 +03:00
|
|
|
# frozen_string_literal: false
|
2008-01-07 18:32:07 +03:00
|
|
|
require 'test/unit'
|
|
|
|
require 'timeout'
|
|
|
|
|
|
|
|
class TestTimeout < Test::Unit::TestCase
|
2021-09-25 00:19:51 +03:00
|
|
|
|
2023-07-03 12:26:40 +03:00
|
|
|
def test_work_is_done_in_same_thread_as_caller
|
|
|
|
assert_equal Thread.current, Timeout.timeout(10){ Thread.current }
|
|
|
|
end
|
|
|
|
|
|
|
|
def test_work_is_done_in_same_fiber_as_caller
|
|
|
|
require 'fiber' # needed for ruby 3.0 and lower
|
|
|
|
assert_equal Fiber.current, Timeout.timeout(10){ Fiber.current }
|
|
|
|
end
|
|
|
|
|
2021-09-25 00:19:51 +03:00
|
|
|
def test_non_timing_out_code_is_successful
|
|
|
|
assert_nothing_raised do
|
|
|
|
assert_equal :ok, Timeout.timeout(1){ :ok }
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-07-09 09:03:55 +03:00
|
|
|
def test_allows_zero_seconds
|
|
|
|
assert_nothing_raised do
|
|
|
|
assert_equal :ok, Timeout.timeout(0){:ok}
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def test_allows_nil_seconds
|
|
|
|
assert_nothing_raised do
|
|
|
|
assert_equal :ok, Timeout.timeout(nil){:ok}
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2022-05-12 17:20:56 +03:00
|
|
|
def test_included
|
|
|
|
c = Class.new do
|
|
|
|
include Timeout
|
|
|
|
def test
|
|
|
|
timeout(1) { :ok }
|
|
|
|
end
|
|
|
|
end
|
|
|
|
assert_nothing_raised do
|
|
|
|
assert_equal :ok, c.new.test
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2021-09-25 01:15:52 +03:00
|
|
|
def test_yield_param
|
|
|
|
assert_equal [5, :ok], Timeout.timeout(5){|s| [s, :ok] }
|
|
|
|
end
|
|
|
|
|
2008-01-07 18:32:07 +03:00
|
|
|
def test_queue
|
2016-08-30 09:22:30 +03:00
|
|
|
q = Thread::Queue.new
|
2008-01-07 18:32:07 +03:00
|
|
|
assert_raise(Timeout::Error, "[ruby-dev:32935]") {
|
2015-07-13 13:07:01 +03:00
|
|
|
Timeout.timeout(0.01) { q.pop }
|
2008-01-07 18:32:07 +03:00
|
|
|
}
|
|
|
|
end
|
|
|
|
|
2009-04-28 14:10:05 +04:00
|
|
|
def test_timeout
|
2014-05-28 07:05:48 +04:00
|
|
|
assert_raise(Timeout::Error) do
|
2014-05-27 12:00:19 +04:00
|
|
|
Timeout.timeout(0.1) {
|
2014-05-28 07:05:48 +04:00
|
|
|
nil while true
|
2009-04-28 14:10:05 +04:00
|
|
|
}
|
|
|
|
end
|
|
|
|
end
|
2010-04-19 13:58:09 +04:00
|
|
|
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
def test_nested_timeout
|
|
|
|
a = nil
|
|
|
|
assert_raise(Timeout::Error) do
|
|
|
|
Timeout.timeout(0.1) {
|
|
|
|
Timeout.timeout(1) {
|
|
|
|
nil while true
|
|
|
|
}
|
|
|
|
a = 1
|
|
|
|
}
|
|
|
|
end
|
|
|
|
assert_nil a
|
|
|
|
end
|
|
|
|
|
2023-07-04 22:45:28 +03:00
|
|
|
class MyNewErrorOuter < StandardError; end
|
|
|
|
class MyNewErrorInner < StandardError; end
|
|
|
|
|
|
|
|
# DOES NOT fail with
|
|
|
|
# - raise new(message) if exc.equal?(e)
|
|
|
|
# + raise new(message) if exc.class == e.class
|
|
|
|
def test_nested_timeout_error_identity
|
|
|
|
begin
|
|
|
|
Timeout.timeout(0.1, MyNewErrorOuter) {
|
|
|
|
Timeout.timeout(1, MyNewErrorInner) {
|
|
|
|
nil while true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rescue => e
|
|
|
|
assert e.class == MyNewErrorOuter
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
# DOES fail with
|
|
|
|
# - raise new(message) if exc.equal?(e)
|
|
|
|
# + raise new(message) if exc.class == e.class
|
|
|
|
def test_nested_timeout_which_error_bubbles_up
|
|
|
|
raised_exception = nil
|
|
|
|
begin
|
|
|
|
Timeout.timeout(0.1) {
|
|
|
|
Timeout.timeout(1) {
|
|
|
|
raise Timeout::ExitException.new("inner message")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rescue Exception => e
|
|
|
|
raised_exception = e
|
|
|
|
end
|
|
|
|
|
2023-11-08 09:39:19 +03:00
|
|
|
assert_equal 'inner message', raised_exception.message
|
2023-07-04 22:45:28 +03:00
|
|
|
end
|
|
|
|
|
2010-04-19 13:58:09 +04:00
|
|
|
def test_cannot_convert_into_time_interval
|
|
|
|
bug3168 = '[ruby-dev:41010]'
|
|
|
|
def (n = Object.new).zero?; false; end
|
|
|
|
assert_raise(TypeError, bug3168) {Timeout.timeout(n) { sleep 0.1 }}
|
|
|
|
end
|
2013-08-26 10:27:48 +04:00
|
|
|
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
def test_skip_rescue_standarderror
|
2013-08-26 10:27:48 +04:00
|
|
|
e = nil
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
assert_raise_with_message(Timeout::Error, /execution expired/) do
|
2015-07-13 13:07:01 +03:00
|
|
|
Timeout.timeout 0.01 do
|
2013-08-26 10:27:48 +04:00
|
|
|
begin
|
|
|
|
sleep 3
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
rescue => e
|
2022-05-12 17:20:56 +03:00
|
|
|
flunk "should not see any exception but saw #{e.inspect}"
|
2013-08-26 10:27:48 +04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
end
|
|
|
|
|
|
|
|
def test_raises_exception_internally
|
|
|
|
e = nil
|
|
|
|
assert_raise_with_message(Timeout::Error, /execution expired/) do
|
|
|
|
Timeout.timeout 0.01 do
|
|
|
|
begin
|
|
|
|
sleep 3
|
|
|
|
rescue Exception => exc
|
|
|
|
e = exc
|
|
|
|
raise
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
assert_equal Timeout::ExitException, e.class
|
2013-08-26 10:27:48 +04:00
|
|
|
end
|
2013-08-27 12:18:50 +04:00
|
|
|
|
|
|
|
def test_rescue_exit
|
|
|
|
exc = Class.new(RuntimeError)
|
|
|
|
e = nil
|
|
|
|
assert_nothing_raised(exc) do
|
2015-07-13 13:07:01 +03:00
|
|
|
Timeout.timeout 0.01, exc do
|
2013-08-27 12:18:50 +04:00
|
|
|
begin
|
|
|
|
sleep 3
|
|
|
|
rescue exc => e
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2015-11-03 15:15:31 +03:00
|
|
|
assert_raise_with_message(exc, 'execution expired') {raise e if e}
|
2013-08-27 12:18:50 +04:00
|
|
|
end
|
2014-01-07 07:42:37 +04:00
|
|
|
|
|
|
|
def test_custom_exception
|
|
|
|
bug9354 = '[ruby-core:59511] [Bug #9354]'
|
|
|
|
err = Class.new(StandardError) do
|
|
|
|
def initialize(msg) super end
|
|
|
|
end
|
|
|
|
assert_nothing_raised(ArgumentError, bug9354) do
|
2015-07-13 13:07:01 +03:00
|
|
|
assert_equal(:ok, Timeout.timeout(100, err) {:ok})
|
2014-01-07 07:42:37 +04:00
|
|
|
end
|
2015-11-03 15:15:31 +03:00
|
|
|
assert_raise_with_message(err, 'execution expired') do
|
2015-07-13 13:07:01 +03:00
|
|
|
Timeout.timeout 0.01, err do
|
2015-07-11 02:47:55 +03:00
|
|
|
sleep 3
|
|
|
|
end
|
|
|
|
end
|
2016-09-07 15:32:04 +03:00
|
|
|
assert_raise_with_message(err, /connection to ruby-lang.org expired/) do
|
|
|
|
Timeout.timeout 0.01, err, "connection to ruby-lang.org expired" do
|
2016-09-07 11:21:56 +03:00
|
|
|
sleep 3
|
|
|
|
end
|
|
|
|
end
|
2014-01-07 07:42:37 +04:00
|
|
|
end
|
2014-01-07 07:43:08 +04:00
|
|
|
|
|
|
|
def test_exit_exception
|
2015-07-10 16:05:53 +03:00
|
|
|
assert_raise_with_message(Timeout::Error, "boon") do
|
|
|
|
Timeout.timeout(10, Timeout::Error) do
|
|
|
|
raise Timeout::Error, "boon"
|
2014-01-07 07:43:08 +04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
2014-01-08 08:12:39 +04:00
|
|
|
|
2021-04-20 20:34:11 +03:00
|
|
|
def test_raise_with_message
|
|
|
|
bug17812 = '[ruby-core:103502] [Bug #17812]: Timeout::Error doesn\'t let two-argument raise() set a new message'
|
|
|
|
exc = Timeout::Error.new('foo')
|
|
|
|
assert_raise_with_message(Timeout::Error, 'bar', bug17812) do
|
|
|
|
raise exc, 'bar'
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2014-01-08 08:12:39 +04:00
|
|
|
def test_enumerator_next
|
|
|
|
bug9380 = '[ruby-dev:47872] [Bug #9380]: timeout in Enumerator#next'
|
|
|
|
e = (o=Object.new).to_enum
|
|
|
|
def o.each
|
|
|
|
sleep
|
|
|
|
end
|
|
|
|
assert_raise_with_message(Timeout::Error, 'execution expired', bug9380) do
|
|
|
|
Timeout.timeout(0.01) {e.next}
|
|
|
|
end
|
|
|
|
end
|
2015-07-10 16:05:53 +03:00
|
|
|
|
|
|
|
def test_handle_interrupt
|
|
|
|
bug11344 = '[ruby-dev:49179] [Bug #11344]'
|
|
|
|
ok = false
|
|
|
|
assert_raise(Timeout::Error) {
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
Thread.handle_interrupt(Timeout::ExitException => :never) {
|
2015-07-10 16:05:53 +03:00
|
|
|
Timeout.timeout(0.01) {
|
|
|
|
sleep 0.2
|
|
|
|
ok = true
|
[ruby/timeout] Raise exception instead of throw/catch for timeouts
(https://github.com/ruby/timeout/pull/30)
throw/catch is used for non-local control flow, not for exceptional situations.
For exceptional situations, raise should be used instead. A timeout is an
exceptional situation, so it should use raise, not throw/catch.
Timeout's implementation that uses throw/catch internally causes serious problems.
Consider the following code:
```ruby
def handle_exceptions
yield
rescue Exception => exc
handle_error # e.g. ROLLBACK for databases
raise
ensure
handle_exit unless exc # e.g. COMMIT for databases
end
Timeout.timeout(1) do
handle_exceptions do
do_something
end
end
```
This kind of design ensures that all exceptions are handled as errors, and
ensures that all exits (normal exit, early return, throw/catch) are not
handled as errors. With Timeout's throw/catch implementation, this type of
code does not work, since a timeout triggers the normal exit path.
See https://github.com/rails/rails/pull/29333 for an example of the damage
Timeout's design has caused the Rails ecosystem.
This switches Timeout.timeout to use raise/rescue internally. It adds a
Timeout::ExitException subclass of exception for the internal raise/rescue,
which Timeout.timeout will convert to Timeout::Error for backwards
compatibility. Timeout::Error remains a subclass of RuntimeError.
This is how timeout used to work in Ruby 2.0. It was changed in Ruby 2.1,
after discussion in [Bug #8730] (commit
https://github.com/ruby/timeout/commit/238c003c921e in the timeout repository). I
think the change from using raise/rescue to using throw/catch has caused
significant harm to the Ruby ecosystem at large, and reverting it is
the most sensible choice.
From the translation of [Bug #8730], it appears the issue was that
someone could rescue Exception and not reraise the exception, causing
timeout errors to be swallowed. However, such code is broken anyway.
Using throw/catch causes far worse problems, because then it becomes
impossible to differentiate between normal control flow and exceptional
control flow.
Also related to this is [Bug #11344], which changed how
Thread.handle_interrupt interacted with Timeout.
https://github.com/ruby/timeout/commit/f16545abe6
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
2023-06-22 21:24:40 +03:00
|
|
|
Thread.handle_interrupt(Timeout::ExitException => :on_blocking) {
|
2015-07-10 16:05:53 +03:00
|
|
|
sleep 0.2
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(ok, bug11344)
|
|
|
|
end
|
2022-05-15 14:43:29 +03:00
|
|
|
|
|
|
|
def test_fork
|
|
|
|
omit 'fork not supported' unless Process.respond_to?(:fork)
|
|
|
|
r, w = IO.pipe
|
|
|
|
pid = fork do
|
|
|
|
r.close
|
|
|
|
begin
|
|
|
|
r = Timeout.timeout(0.01) { sleep 5 }
|
|
|
|
w.write r.inspect
|
|
|
|
rescue Timeout::Error
|
|
|
|
w.write 'timeout'
|
|
|
|
ensure
|
|
|
|
w.close
|
|
|
|
end
|
|
|
|
end
|
|
|
|
w.close
|
|
|
|
Process.wait pid
|
|
|
|
assert_equal 'timeout', r.read
|
|
|
|
r.close
|
|
|
|
end
|
2022-09-25 12:14:11 +03:00
|
|
|
|
|
|
|
def test_threadgroup
|
|
|
|
assert_separately(%w[-rtimeout], <<-'end;')
|
|
|
|
tg = ThreadGroup.new
|
|
|
|
thr = Thread.new do
|
|
|
|
tg.add(Thread.current)
|
|
|
|
Timeout.timeout(10){}
|
|
|
|
end
|
|
|
|
thr.join
|
|
|
|
assert_equal [].to_s, tg.list.to_s
|
|
|
|
end;
|
|
|
|
end
|
|
|
|
|
2023-02-15 21:26:13 +03:00
|
|
|
# https://github.com/ruby/timeout/issues/24
|
2023-02-12 17:23:37 +03:00
|
|
|
def test_handling_enclosed_threadgroup
|
|
|
|
assert_separately(%w[-rtimeout], <<-'end;')
|
2023-02-15 21:26:13 +03:00
|
|
|
Thread.new {
|
|
|
|
t = Thread.current
|
|
|
|
group = ThreadGroup.new
|
|
|
|
group.add(t)
|
|
|
|
group.enclose
|
|
|
|
|
|
|
|
assert_equal 42, Timeout.timeout(1) { 42 }
|
|
|
|
}.join
|
2023-02-12 17:23:37 +03:00
|
|
|
end;
|
|
|
|
end
|
2009-04-28 14:10:05 +04:00
|
|
|
end
|