ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "matz (Yukihiro Matsumoto)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:107887] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations.
Date: Mon, 14 Mar 2022 04:28:42 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-96828.20220314042841.3344@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-18630.20220314024343.3344@ruby-lang.org

Issue #18630 has been updated by matz (Yukihiro Matsumoto).


I am positive about introducing safer timeout feature.
But I have several concerns:

* time-out may happen from I/O blocking operations or other CPU bound operation. This proposal only covers I/O blocking. Is it OK?
* time-out may not be caused by a single I/O operation, but by multiple operations. This proposal should be updated to address it (maybe specifying time-bound by the specific time point).
* some I/O operation methods takes `timeout` keyword argument. We need to confirm they are consistent with this proposal.

Matz.


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

* 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/

  reply	other threads:[~2022-03-14  4:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14  2:43 [ruby-core:107886] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations ioquatix (Samuel Williams)
2022-03-14  4:28 ` matz (Yukihiro Matsumoto) [this message]
2022-03-14  9:05 ` [ruby-core:107889] " Eregon (Benoit Daloze)
2022-03-14 14:52 ` [ruby-core:107891] " ioquatix (Samuel Williams)
2022-03-17  2:08 ` [ruby-core:107935] " ioquatix (Samuel Williams)
2022-03-17 12:06 ` [ruby-core:107949] " Eregon (Benoit Daloze)
2022-03-17 15:42 ` [ruby-core:107957] " ioquatix (Samuel Williams)
2022-03-21 15:52 ` [ruby-core:108004] " byroot (Jean Boussier)
2022-03-21 16:59 ` [ruby-core:108007] " Eregon (Benoit Daloze)
2022-03-21 17:11 ` [ruby-core:108008] " Eregon (Benoit Daloze)
2022-03-21 19:30 ` [ruby-core:108009] " ioquatix (Samuel Williams)
2022-03-28 10:24 ` [ruby-core:108099] " Eregon (Benoit Daloze)
2022-03-29 21:58 ` [ruby-core:108112] " ioquatix (Samuel Williams)
2022-03-31 10:58 ` [ruby-core:108136] " Eregon (Benoit Daloze)
2022-03-31 11:25 ` [ruby-core:108138] " ioquatix (Samuel Williams)
2022-03-31 11:46 ` [ruby-core:108139] " ioquatix (Samuel Williams)
2022-03-31 17:15 ` [ruby-core:108145] " Eregon (Benoit Daloze)
2022-03-31 22:52 ` [ruby-core:108149] " ioquatix (Samuel Williams)
2022-04-21  9:20 ` [ruby-core:108338] " Eregon (Benoit Daloze)
2022-04-21  9:36 ` [ruby-core:108340] " Eregon (Benoit Daloze)
2022-07-20 10:13 ` [ruby-core:109257] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=` for blocking operations ioquatix (Samuel Williams)
2022-07-20 11:48 ` [ruby-core:109262] " ioquatix (Samuel Williams)
2022-09-20 22:49 ` [ruby-core:109967] " ioquatix (Samuel Williams)
2022-09-22 10:22 ` [ruby-core:109996] " ioquatix (Samuel Williams)
2022-09-23  6:35 ` [ruby-core:110032] " ioquatix (Samuel Williams)
2022-10-07  2:28 ` [ruby-core:110222] " ioquatix (Samuel Williams)
2022-10-07  8:32 ` [ruby-core:110225] " matz (Yukihiro Matsumoto)
2022-10-08  7:34 ` [ruby-core:110234] " ioquatix (Samuel Williams)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-96828.20220314042841.3344@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).