`Condition` is using `Time.now`

[pitr-ch]

see https://github.com/ruby-concurrency/concurrent-ruby/blob/master/lib/concurrent/atomic/condition.rb#L42

It may cause performance issue and I am also not entirely sure if it is save to be used here.
We rely on this class a lot, we will have to find other way or give up the timeout detection.

[jdantonio]

@pitr-ch What's the concern with Time.now?

[pitr-ch]

Hm it turns out Time.now is actually much faster than I've expected. It was around 1.8601 µs (microseconds), so about 10times slower than a method call (on MRI). The performance impact is not that big as I thought, still this should be as fast as possible so if we can we should consider removing it or using just ConditionVariable if the time-out detection is not needed.

Nevertheless there is another issue, when somebody changes time in the system this can start giving bad results.

[jdantonio]

On MRI this is being addressed in PR #253 by using Ruby's Process::CLOCK_MONOTONIC (see here) which I didn't know existed. So I did some Googling to see if we could do something similar in Java and we can: System.nanoTime() (see here). Once we PR #253 merged I'll do a JRuby-specific update.

[tenderlove]

@jdantonio I think JRuby supports this monotonic API. @headius is that true?

[jdantonio]

Confirmed that Rbx does not have this feature. https://twitter.com/rubinius/status/570336877250678786

[headius]

JRuby should support the monotonic clock already (based on nanoTime, unsurprisingly).

[jdantonio]

@headius Which versions of JRuby? It seems to me that it only supports this API in jruby-head but not the 1.7.x branch? Can you confirm? If so, we can easily use System.nanoTime() directly on versions of JRuby without Process.clock_gettime.

[headius]

Oh yes, sorry...my brain is already running on JRuby 9k :-D

Process::CLOCK_MONOTONIC is a Ruby 2.x feature, and JRuby 1.7 only implements 1.9.3. System.nanoTime should be pretty cheap, though.

[jdantonio]

Addressed in #253 and #254.