Re: [boost] Boost Timer Update

From: Philippe Vaucher (philippe.vaucher_at_[hidden])
Date: 2006-11-01 05:47:42

>
> I guess it depends on what you're using the timer for. I really don't mind
> either way as long as the behaviour is well-documented. When I'm using a
> "microsecond timer", it is because I want to measure short intervals, not
> long
> ones. But perhaps there should be clearer ways of specifying the
> precision/accuracy/resolution trade-offs desired?

At the moment I think about an api like this :

   - portable: microsec_timer: documented as most robust timer, not the
   best resolution one, good enough for 90% of the timings.
   - portable: second_timer: this one is kindof obvious, no need to
   describe much
   - portable: clock_timer: timer based on std::clock, documentation
   about clock() issue and resolutions
   - windows: qpc_timer: documented as best resolution, not thread safe &
   multi core problem. Hability to set a macro that automatically calls
   SetThreadAffinityMask()
   - windows: tgt_timer: documented as a good alternative to qpc ( I
   think tgt > GetSytemTimeAsFileTime )
   - To discuss but I may add those timers :
      - windows: gst_timer: uses GetSystemTimeAsFileTime (actually
      microsec_clock already uses gst but it may change so why not offer an
      explicit one).
      - windows: gtc_timer: uses GetTickCount()
      - linux: gtod_timer: uses gettimeofday() (actually
      microsec_clock already uses gtod but it may change so why not offer an
      explicit one).

 If you know of other linux timers that'd be worth using please mention them
thank you.

I think that if each timer type is well documented about resolution, thread
safety, multi-core issues and all the others gotcha's those timers are
giving us headaches about, then the user can choose the timer he wants and
take the risk himself. Of course I think we should suggest the users to use
microsec_timer for portable code. I kinda like this approach because the
user is free to make his choices and aware of the issues... At the moment
I'm not very happy about using QPC for microsec_timer because it looks like
the pros (satisfies some people, not the majority?) doesn't outweight the
cons (all the issues about QPC).

On second thought, apparently Java calls their QPC implementation is called
> "nano" instead. Perhaps we could use that terminology as well?
>

I already thought a bit about this and at start my timers were named
nanosec_timer or smth, but then this idea collided with date_time::microsec
terminology and I decided to be consistent with other parts of boost.

Philippe