Boost logo

Boost :

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>> writes:
> >
> > "Darryl Green" < <at>> 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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at