"Darryl Green" <darryl.green@unitab.com.au> wrote in message news:loom.20040422T041504-129@post.gmane.org...
Jeff Garland <jeff <at> crystalclearsoftware.com> writes:
I've been offline a while. Still interested in improving time support in boost threads though.
On Tue, 20 Apr 2004 08:16:06 +0000 (UTC), Darryl Green wrote
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);
I agree boost::posix_time::time_duration would be fine to use as a duration representation. Broadly speaking, time_duration would be used where
I'm still interested too, though I haven't been commenting much on this thread (not having much of importance to contribute yet). posix uses
the timespec struct.
Bill and I had a discussion about moving toward this in the
future, but never
had a chance to do this.
Ok - but what is the time part of this then? xtime is a duration since some epoch. Do you mean to directly replace xtime with a duration type?
I think xtime needs replacing with a number of distinct clock types. If we simply use a duration type everywhere, there is a possibility that someone passes a duration intended to represent a time when used with epoch A to a function that is using clock/epoch B. This strikes me as something
If this was a public discussion, do you have a link to it? I'd be interested in reading through it. that should
be detected at compile time. If all times use the same duration type it is obviously simple enough to perform sensible conversions where needed.
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
As far as I know, all timers are relative...
Sorry: The root of this lies in the fact that xtime's TIME_UTC is "wallclock" time, while the duration passed to the windows Wait.. functions is used by a "tick count" clock with an undefined epoch (afaik).
I agree that this is the root of the OP's problem. For what it's worth, in my response to the OP I made a distinction between "absolute" and "relative" times, indicating there was good reason for Boost.Thread to use an absolute time with the timed_wait function. Using stricter terminology, what I meant by absolute time was time relative to a fixed epoch; what I meant by relative time is time relative to a non-fixed epoch (i.e., relative to the time when the timed_wait function was called). I still think it's a good idea in general to pass what I was calling an absolute time to timed_wait. What do you think? [snipped discussion of types of time]
As an example using boost thread:
extern bool something_done; void start_something();
condition<up_time> cond;
mutex m; lock lk<m>;
bool done_by(time<up_time> tm) { while (!something_done) { if (!cond.timed_wait(lk, tm)) return false; } return true; }
int main(int, char*[]) { time<up_time> a(minutes(5)); // construct from duration since epoch time<utc_time> b(date(min_date), minutes(5)); // using
I didn't comment on this when you mentioned it the first time because I wanted to think about it first, but I'd be pretty hesitant to turn the condition class into a template class merely for the sake of the timed_wait functions. I could see templating the timed_wait functions themselves if necessary, but templating the whole condition class seems to me like trying to solve the problem at the wrong level. posix_time-like ctor
start_something(); if (done_by(a)) cout << "Did something within 5 minutes of system start." <<
endl;
if (done_by(b)) // won't compile cout << "This is a very early computer!" << endl;
return 0; }
Have I somehow drawn the clock/time/duration distinctions in the wrong places, or is the above a reasonable approach? I've had a look at the implementation of date_time and I think it might fit ok with the model I was
[snipped "a more realistic use case"] thinking of
where any time type is basically identical except for some sort of clock dependent trait/policy.
Using date_time this would be time_system. This looks like a reasonable place to start but the base_time seems to require that:
A time has a date component. A time has a zone.
I guess one could write a time_system that had only a vestigial concept of date and zone? Is there a way of making a pure day based date (no fancy julian date calcs)?
Regards Darryl Green.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost