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