From: Jeff Garland (jeff_at_[hidden])
Date: 2004-04-20 06:47:54
On Tue, 20 Apr 2004 08:16:06 +0000 (UTC), Darryl Green wrote
> Michael Glassford <glassfordm <at> hotmail.com> writes:
>
> >
> > "Darryl Green" <darryl.green <at> unitab.com.au> wrote in message
> That said, is this the right thing to do? xtime is a very "c" sort
> of a creature and seems to lack basic type safety. Wouldn't it be
> better to have a different time type for each clock type? A common
> duration type could be used.
I might suggest boost::posix_time::time_duration and its breathren. Then you
could expressions like:
time_duration td = milliseconds(100)+microseconds(20);
Bill and I had a discussion about moving toward this in the future, but never
had a chance to do this.
> One way or another, changing the time type is easy, but the actual
> timed wait implementation is harder, as evidenced by maq's test on
> windows. The root of this lies in the fact that xtime's TIME_UTC is
> "wallclock" time, while the relative time used by the windows Wait..
> functions is a "tick count" (afaik) and isn't affected by changing
> the system time. Unless windows supports some form of timer event
> that uses "wallclock" time there doesn't seem to be a way to fix
> this. Posix systems should act consistently (CLOCK_REALTIME used
> throughout) afaik.
As far as I know, all timers are relative...
>...
> Does the general direction sound ok? Basically make a timer that
> takes the clock type as a policy and make classes that support
> timeouts (condvars, mutexes so far) templated on the timer type?
> Provide partial specializations for for things like full pthreads-
> based clock selection, but can allow (as per current windows impl) a
> fallback to using a duration based timeout running whatever clock
> the OS uses for timeouts?
In general the separation of the clock from the representation of time is the
correct approach. date_time does this because there is a recognition that
different platforms (and systems) have different clock sources that can be
adapted to produces a particular time representation with different resolution
and accuracy attributes. From what I'm reading here this is exactly the issue
you are facing...
Jeff