[ruby-core:108004] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations.

["byroot (Jean Boussier)" <noreply@ruby-lang.org>]

Issue #18630 has been updated by byroot (Jean Boussier).


> I'm not sure a timeout per IO instance makes sense,

I think it does for various network clients. See for example [`net-protocol`'s `BufferedIO` class](https://github.com/ruby/net-protocol/blob/088e52609a8768c1e6156fa6c5609bbfadd44320/lib/net/protocol.rb#L115-L302) which backs Net::HTTP and others.

If you want to have a timeout on your network client, you are basically to `read_nonblock / write_nonblock`, so for most line based protocols (such as HTTP but also memcached, redis, etc) you can't use `IO#gets`. This means you need to buffer your reads to find the newline, so now you have the Ruby internal 16KiB IO buffer, plus the `BufferedIO` 16KiB buffer, and you end up calling `String#slice!` repeatedly on that Ruby String which is atrocious for performance.

I recently had to do [the same thing for a new Redis client I'm working on](https://github.com/redis-rb/redis-client/blob/a9b198ec1f312c30f5c5b94be3131c228a950aa8/lib/redis_client/buffered_io.rb), but to save on performance I don't `slice!` the buffer, but keep a numeric `@offset` alongside.

If I understand this proposal correctly, it would allow me to directly call `IO#gets` with the timeout I desire, which would allow me to not have my own buffer and solely rely on the internal one.

That being said, if there was some kind of `IO.timeout(timeout) {}` it would work too. I guess both have their pros and cons.


----------------------------------------
Feature #18630: Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations.
https://bugs.ruby-lang.org/issues/18630#change-96959

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
----------------------------------------
I would like us to consider introducing a general timeout for all blocking operations. This timeout can be 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/