Date: 2001-08-03 09:54:42
--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> To: <boost_at_y...>
> Sent: Friday, August 03, 2001 8:46 AM
> Subject: [boost] Re: xtime
> > As for exposing the stuff in timeconv.inl, I'm not so sure. These
> > routines are used to translate to/from the native types for the
> > various platforms, and it's just an (unfortunate) coincedence that
> > the Win32 type is a duration. Originally all timed operations in
> > Boost.Threads followed the Win32 route using durations, mostly
> > because of my own bias towards this platform, until you realize
> > a duration wait for a condition is extremely problematic. The
> > is that the condition may return from a wait when the logically
> > associated predicate is not/no longer true and the loop should re-
> > enter the wait. If a duration were used you'd have to recalculate
> > the duration before entering the loop again.
> True, but couldn't the condition could do the conversion from
> absolute time itself? IMO this is a bit more user friendly since
> the time the intention is to wait for a duration of time, not a
For the waits that take a predicate, yes it could. For the waits
meant to be called within a while loop, no it can't.
> > To wait for a duration you simply create an xtime instance and add
> > the seconds and nanoseconds, an operation that really doesn't
> > function.
> The existance and usefulness of to_time() seem to contradict that
> IMO. At least in the case of condition::timed_wait(), which
appears to want
> an absolute time (not a duration).
Not when you read on. :)
> > The to_time() routine in timeconv.inl exists solely to
> > translate milliseconds to seconds and nanoseconds, something that
> > typically won't be needed by programmers (they should precalculate
> > this stuff instead of doing it at run time).
> It does more than that, it converts a duration to an absolute time,
> xtime_get(). Because it depends on the current time, I don't see
> precalculation is possible.
If I want to wait 1 millisecond the code is.
xt.nsec += 1000000;
This is precalculated instead of being calculated at runtime.
> > In any event, the conversions to and from milliseconds would be
> > only ones that you could argue for exposing in any event.
> I should have been more specific--to_time() and to_duration() are
> that I think are generally useful.
What purpose do you see for to_duration()?
BTW, what's really needed here are time and duration classes so that
a wait is as simple as:
cv.wait(dtime() + duration(0, 1000000));
But this is beyond the scope of a threading library. The only reason
for inclusion of an xtime concept at all is to give use the minimum
functionality needed to represent times (with a good resolution) for
the waits. The xtime class doesn't really belong in Boost.Threads,
and I'm not sure how I'll factor this before submission. But I'm not
going to provide any more than this minimal amount of functionality.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk