[#47386] [Backport92 - Backport #6958][Open] buggy BigDecimal#integer? — "adrianomitre (Adriano Mitre)" <adriano.mitre@...>
7 messages
2012/09/01
[#47409] [ruby-trunk - Feature #6973][Open] Add an #integral? method to Numeric to test for whole-number values — "regularfry (Alex Young)" <alex@...>
12 messages
2012/09/03
[#47444] [ruby-trunk - Bug #6986][Open] Inconsistent result of BigDecimal#power — "phasis68 (Heesob Park)" <phasis@...>
7 messages
2012/09/06
[#47453] [ruby-trunk - Bug #6994][Open] yield plus splat unwraps too much — "headius (Charles Nutter)" <headius@...>
8 messages
2012/09/07
[#47460] [ruby-trunk - Bug #6997][Open] Improve documentation for OptionParser — "eike.rb (Eike Dierks)" <eike@...>
7 messages
2012/09/08
[#47465] [ruby-trunk - Feature #7003][Assigned] Please decide. MVM to be with 2.0? — "shyouhei (Shyouhei Urabe)" <shyouhei@...>
3 messages
2012/09/10
[#47523] [ruby-trunk - Feature #7022][Open] add event hook for garbage collection — "rogerdpack (Roger Pack)" <rogerpack2005@...>
7 messages
2012/09/14
[#47531] [ruby-trunk - Feature #7022] add event hook for garbage collection
— "rogerdpack (Roger Pack)" <rogerpack2005@...>
2012/09/14
[#47540] autoload & require — Xavier Noria <fxn@...>
Hi,
4 messages
2012/09/15
[#47562] feature request: thread pool class — Roger Pack <rogerdpack2@...>
It has always seemed a bit odd to me that Ruby's sdlib doesn't have some kind of
4 messages
2012/09/17
[#47638] [ruby-trunk - Bug #7046][Open] ERB#run and ERB#result are not safe for concurrent use — "headius (Charles Nutter)" <headius@...>
11 messages
2012/09/21
[#47653] [ruby-trunk - Bug #7050][Open] encoding of String#unpack for 'H', 'h', 'B' and 'b' — "Eregon (Benoit Daloze)" <redmine@...>
6 messages
2012/09/22
[#47655] [ruby-trunk - Feature #7051][Open] Extend caller_locations API to include klass and bindings. Allow caller_locations as a method hanging off Thread. — "sam.saffron (Sam Saffron)" <sam.saffron@...>
13 messages
2012/09/23
[#47709] [ruby-trunk - Bug #7076][Open] TestUnicodeEscape#test_basic failure on Windows — "h.shirosaki (Hiroshi Shirosaki)" <h.shirosaki@...>
4 messages
2012/09/27
[#47719] [ruby-trunk - Bug #7082][Open] Process.kill 0 in windows can return spurious success — "rogerdpack (Roger Pack)" <rogerpack2005@...>
6 messages
2012/09/28
[#47730] [ruby-trunk - Bug #7085][Open] Subversion → GitHub gateway stops. — "shyouhei (Shyouhei Urabe)" <shyouhei@...>
27 messages
2012/09/29
[#47731] [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/09/29
[#47743] Re: [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— Evan Phoenix <evan@...>
2012/09/29
Hello shyouhei, =20
[#47746] Re: [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— Urabe Shyouhei <shyouhei@...>
2012/09/30
On 09/30/2012 02:33 AM, Evan Phoenix wrote:
[#48020] [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/10/16
[#48953] [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— "shyouhei (Shyouhei Urabe)" <shyouhei@...>
2012/11/05
[#49123] Re: [ruby-trunk - Bug #7085] Subversion → GitHub gateway stops.
— Evan Phoenix <evan@...>
2012/11/08
So sorry for the continual delay. I'm setting this up right now but it ap=
[#47735] [ruby-trunk - Bug #7087][Open] ::ConditionVariable#wait does not work with Monitor because Monitor#sleep does not exist — "rklemme (Robert Klemme)" <shortcutter@...>
10 messages
2012/09/29
[ruby-core:47744] [ruby-trunk - Bug #7086] ConditionVariable#wait has meaningless return value
From:
"rklemme (Robert Klemme)" <shortcutter@...>
Date:
2012-09-29 18:44:43 UTC
List:
ruby-core #47744
Issue #7086 has been updated by rklemme (Robert Klemme).
kosaki (Motohiro KOSAKI) wrote:
> I think Java API spec is crazy and buggy.
:-)
> And then, no timeout doesn't mean the condition become true and an API user always have to ignore the return value and check
> his own condition again.
There is some truth in what you write. In the usual case you certainly need to check your condition. But I think nevertheless that the Java way is not crazy.
> Moreover, we have one another mess. When cv#signal was not only fired but also timeout occur, some OS return timeout occur and
> other return cv#signal received. Both POSIX and Java permit such platform dependency. then, you must not trust the return value.
I disagree that the named facts make the return value useless. See below.
> I'm hesitate to implement it because it seems bring a lot of trouble than worth.
We certainly need to give a bit more thought to this. So, the condition needs to be checked to be sure it is met. But: in case of timeout you can do a quick exit of the loop if #wait has a proper return value. The usage pattern would look like this:
def do_whatever(timeout)
target = Time.now + timeout
lock.synchronize do
until condition
cv.wait(target - Time.now) or return :fail
end
whatever
end
:ok
end
The race condition between spurious wakeup, timeout and signaling is really irrelevant. The reason is this: if any two of them happen at approximately the same time it doesn't matter whether one of them is a few microseconds earlier or the implementation prefers one of them. The outcome (i.e. return value) is random for the observer anyway. You also cannot create a test which would verify certain behavior reliably because you cannot control execution order down to the nanosecond.
But: if the timeout is detected it is extremely useful to indicate that fact via the return value. Otherwise the idiom shown above would become more complex:
def do_whatever(timeout)
target = Time.now + timeout
lock.synchronize do
until condition
sec = target - Time.now
return :fail if sec <= 0
cv.wait sec
end
whatever
end
:ok
end
If we allow instances of Time and DateTime as "timeout" argument to #wait things become even simpler:
def do_whatever(timeout)
target = Time.now + timeout
lock.synchronize do
until condition
cv.wait target or return :fail
end
whatever
end
:ok
end
It would also be nice if MonitorMixin::ConditionVariable allowed for a timeout argument to #wait_until and #wait_while. Then we could remove the loop altogether yet retain the time limitation. :-)
----------------------------------------
Bug #7086: ConditionVariable#wait has meaningless return value
https://bugs.ruby-lang.org/issues/7086#change-29798
Author: rklemme (Robert Klemme)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 1.9.3p194 (2012-04-20) [i686-linux]
I consider this an API bug: when invoked with a timeout value the caller cannot distinguish from the return value whether the condition has been signaled or the time has run out. Consider how Java does it: http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html#await(long,%20java.util.concurrent.TimeUnit) and http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html#awaitUntil(java.util.Date)
There's another issue exhibited through the script but I will create a separate ticket for this.
--
http://bugs.ruby-lang.org/