From: "Eregon (Benoit Daloze)" Date: 2022-03-31T10:58:20+00:00 Subject: [ruby-core:108136] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations. Issue #18630 has been updated by Eregon (Benoit Daloze). ioquatix (Samuel Williams) wrote in #note-15: > @eregon it makes sense to me to introduce `IO::Timeout` or `IO::TimeoutError` (not sure timeout is strictly an error?). Basically all exception classes end with `Exception` or `Error` or some other indication of it (see `ri Exception`). So I think `IO::Timeout` is not a good fit, because from the name it's unclear it's an exception class. And the other two timeout exception classes have `Timeout` + `Error` in their full name, so `IO::TimeoutError` seems an obvious fit. `ETIMEDOUT` is not e.g. in read/select/epoll_wait/... man pages as far as I can see locally and I don't even see it in the my local `recv` man page. It seems specific to socket connections, but the timeout we are talking about is more general (e.g., applies to pipes). I think `ETIMEDOUT` is a bad fit, because it is *not* what is actually returned by the syscalls to which we apply the timeout, isn't it? Also I'd consider `Errno::E*` to be low-level exceptions, and not something we'd want for higher-level functionality. > For me, the biggest reason to use a different class would be because we want a more consistent handling of timeouts, across all blocking operations (not just IO ones). If that is useful (so far it seems not to me), that could always be done by a module included by all timeout exception classes. > I hesitate to make this < StandardError as I feel that timeouts are often not strictly "errors" although a timeout can cause an error. `StandardError` is not about being "an error" or not (that's just consistent naming for exception classes), it's whether it's something that is sensible to rescue "as a general failure" / to recover from or not. It is sensible to rescue `IO::TimeoutError` as a general "something failed during the operation" (at least in some cases) and keep going, while it is e.g. never (or almost never) sensible to rescue (without reraising them) `NoMemoryError`/`SystemStackError`. > Maybe we should have: `class TimeoutError` That's a deprecated alias for Timeout::Error: ``` $ ruby -w -rtimeout -e 'p TimeoutError' -e:1: warning: constant ::TimeoutError is deprecated Timeout::Error ``` ---------------------------------------- Feature #18630: Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations. https://bugs.ruby-lang.org/issues/18630#change-97112 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal ---------------------------------------- I would like us to consider introducing a general IO timeout for all (non-)blocking operations, specified per-IO instance. It's useful for ensuring programs don't stop responding or spend an unreasonable amount of time waiting for IO operations. There are effectively two kinds of interfaces that we need to address: - Those that already have a timeout argument (e.g. `wait_readable`) and we follow the existing semantics. - Those that don't have a timeout argument or timeout semantics (e.g. `puts`, `gets`), and thus probably need to raise an exception on timeout. We have three possible kinds of exceptions we could raise: - `Errno::ETIMEDOUT` - `Timeout::Error` (from `timeout.rb`) - Introduce `IO::Timeout` or something similar. Timeout isn't necessarily an error condition. There are different arguments for whether we should define: ```ruby class IO::Timeout < Exception end # or class IO::Timeout < StandardError end ``` I believe the latter (`StandardError`) is more practical but I'm open to either option. I might have more specific arguments later why one is better than the other after testing in a practical system. There is already a PR to try it out: https://github.com/ruby/ruby/pull/5653 -- https://bugs.ruby-lang.org/ Unsubscribe: