[#108552] [Ruby master Bug#18782] Race conditions in autoload when loading the same feature with multiple threads. — "ioquatix (Samuel Williams)" <noreply@...>
Issue #18782 has been reported by ioquatix (Samuel Williams).
11 messages
2022/05/14
[ruby-core:108520] [Ruby master Feature#18774] Add Queue#pop(timeout:)
From:
"Eregon (Benoit Daloze)" <noreply@...>
Date:
2022-05-11 20:39:44 UTC
List:
ruby-core #108520
Issue #18774 has been updated by Eregon (Benoit Daloze). If others feel strongly it should be an exception, I think it should be `Thread::TimeoutError` (we already have `Timeout::Error`, `Regexp::TimeoutError` and probably `IO::TimeoutError` in #18630). I'd inherit from `StandardError` as that's the common ancestor for those. Agreed with @ioquatix that in practice almost nobody wants an exception for something expected like here (i.e., the code would be `queue.pop(timeout: 1.5)` it's clear a timeout is a possible result). Just like everyone tends to use `exception: false` for the `*_nonblock` IO methods. ---------------------------------------- Feature #18774: Add Queue#pop(timeout:) https://bugs.ruby-lang.org/issues/18774#change-97561 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- This has been mentioned many times but somehow was never added. It is useful for many different use cases: * Implementing Timeout#timeout without needing to create a Thread per call which is very inefficient (especially when the timeout is not hit): https://github.com/ruby/timeout/pull/14#issuecomment-1123380880 * @jeremyevans0 I would love a Queue#pop :timeout argument. It would simplify the mutex/condition variable approach currently used for Sequel's connection pool. * @byroot Same. I wanted it so many times * https://bugs.ruby-lang.org/issues/17363 * https://spin.atomicobject.com/2014/07/07/ruby-queue-pop-timeout/ + https://spin.atomicobject.com/2017/06/28/queue-pop-with-timeout-fixed/ * More in my email searches but this seems already plenty I think it should be a keyword argument for clarity, and so there is no confusion with the existing optional argument `non_block=false`. -- https://bugs.ruby-lang.org/ Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>