On May 1, 2013, at 5:04 PM, Sanne Grinovero <[email protected]> wrote:
> On 29 April 2013 18:04, Pedro Ruivo <[email protected]> wrote: >> >> On 04/29/2013 05:53 PM, Mircea Markus wrote: >>> >>> On 29 Apr 2013, at 17:34, Pedro Ruivo wrote: >>> >>>> Hi, >>>> >>>> The TimeService interface is going to replace all the System.nanoTime() >>>> and System.currentTimeMillis() in the code and it will allow to replace >>>> in the test suite in order to provide a better control over the time >>>> dependent code (if needed). >>>> >>>> The objective of this email is to discuss possible implementation and >>>> interface that will cover the needs of everybody (or at least try it). >>>> Later I'll create a JIRA and start the implementation (except if someone >>>> really wants to implement it :P) >>>> >>>> * Interface: >>>> >>>> //return the current time in nanoseconds and milliseconds respectively >>>> long nowNanos() >>>> long nowMillis() >>> What about time() and wallClockTime() with overloaded methods >>> time(TimeUnit) and wallClockTime(TimeUnit)? >> >> what is the semantic of wallClockTime()? I'm assuming that time() >> returns the current time in nanoseconds... > > There are at least two ways to use a Clock service, as there are > different methods to get the "time" and different concepts of "time" > depending on what your purpose is. > > For example you should never use two invocations of > System.currentTimeMillis() to measure time intervals; it's generally > less accurate but also it is affected by system clock changes, while > nanoTime() is not. The underlying system calls are different, and > depending on the platform the precision guarantees are different and > in some cases the different precision guarantee has a significant > impact on runtime performance of the invocation, for example not all > can be JIT optimized. > > Most of the time we want to use nanoTime(), for example for metrics, > but its precision is valid only in the scope of the machine it's > executed on, so this value is meaningless for something which needs to > be shared with other nodes.. complex, and we might want to switch > implementation for certain use cases depending on the cluster mode. ^ Can you explain further why you'd want a different implementation depending on the cluster mode? > > In other words: the method invoker needs to make it very clear what > its goal is, what it wants to do with the requested "long" as it's not > just a simple universally valid primitive. > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
