[#107867] Fwd: [ruby-cvs:91197] 8f59482f5d (master): add some tests for Unicode Version 14.0.0 — Martin J. Dürst <duerst@...>
To everybody taking care of continuous integration:
3 messages
2022/03/13
[#108090] [Ruby master Bug#18666] No rule to make target 'yaml/yaml.h', needed by 'api.o' — duerst <noreply@...>
Issue #18666 has been reported by duerst (Martin D端rst).
7 messages
2022/03/28
[#108117] [Ruby master Feature#18668] Merge `io-nonblock` gems into core — "Eregon (Benoit Daloze)" <noreply@...>
Issue #18668 has been reported by Eregon (Benoit Daloze).
22 messages
2022/03/30
[ruby-core:107957] [Ruby master Feature#18630] Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations.
From:
"ioquatix (Samuel Williams)" <noreply@...>
Date:
2022-03-17 15:42:32 UTC
List:
ruby-core #107957
Issue #18630 has been updated by ioquatix (Samuel Williams). > I'm not sure it's valuable to have per-IO timeout. `async-io` has used it for years successfully as a protection against slowloris attacks. It ensures that no matter who calls the IO operations, some timeout is associated with it. There is a difference between IO which is usually externally facing and things like Queue, Thread which are internal. I personally have no problem adding timeouts to all those interfaces, and even adding `Thread::Queue#timeout` if that makes sense. However, this PR is mostly just addressing the issue of making non-blocking IO safer in the presence of external malicious actors. ---------------------------------------- Feature #18630: Introduce general `IO#timeout` and `IO#timeout=`for all (non-)blocking operations. https://bugs.ruby-lang.org/issues/18630#change-96907 * 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/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>