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. 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
