Date: 2001-08-03 08:46:03
--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> Is xtime going to continue to play a part in the public interface
> boost thread library (like in condition::timed_wait())? If so, it
> useful to expose some of the functions in timeconv.inl, such as
> to_time(unsigned milliseconds, boost::xtime& xt). It seems more
> want to specify a duration than an absolute time when using
Yes, it will remain in the public interface, and needs to be
documented. Unfortunately, this is a minimalist implementation of
the full spec, since I don't have the expertise to provide a full
implementation. If anyone knows a lot about time algorithms and
would like to volunteer to provide Boost with a full implementation
I'd love to hear it!
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 that
a duration wait for a condition is extremely problematic. The reason
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.
To wait for a duration you simply create an xtime instance and add
the seconds and nanoseconds, an operation that really doesn't need a
function. 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).
In any event, the conversions to and from milliseconds would be the
only ones that you could argue for exposing in any event.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk