From: samuel@... Date: 2021-02-11T23:30:19+00:00 Subject: [ruby-core:102465] [Ruby master Feature#17363] Timeouts Issue #17363 has been updated by ioquatix (Samuel Williams). This seems like a good idea. I agree with the following things: - Move `Timeout` to core. - Add `Timeout::Error` as base class in core. - Add new method for predictable timeout during sleeping operations (e.g. `Timeout.wake` or something similar). In terms of queue and ractor, I'm less inclined to support: - `timeout:` keyword argument. - Custom exception classes for Ractor, Queue and so on. I'm not against it, I'm just not sure if it's useful in practice. I think the latter feature should be separate issue/PR if possible. Finally, I'd also like to suggest that we deprecate `Timeout.timeout` once this is merged. ---------------------------------------- Feature #17363: Timeouts https://bugs.ruby-lang.org/issues/17363#change-90353 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Builtin methods like `Queue.pop` and `Ractor.receive` have no timeout parameter. We should either: - provide such a parameter - and/or provide a `Timeout::wake` that raises an timeout error only if the block is currently sleeping. Details: ```ruby q = Queue.new # ... elem = Timeout::timeout(42) { q.pop } # => It is possible that an element is retreived from the queue but never stored in `elem` elem = Timeout::wake(42) { q.pop } # => Guaranteed that either element is retrieved from the queue or an exception is raised, never both Timeout::wake(42) { loop {} } # => infinite loop # and/or elem = q.pop(timeout: 42) ``` Currently, the only reliable way to have a Queue that accepts a timeout is to re-implement it from scratch. This post describe how involved that can be: https://spin.atomicobject.com/2017/06/28/queue-pop-with-timeout-fixed/ -- https://bugs.ruby-lang.org/ Unsubscribe: