A time value is used for timeouts
We really need to unify the interface between Boost.Thread and Boost.Socket for time values. This will be done at some point using a time_duration (see for an example) from Boost.date_time. -- People/Jeff Garland
So we should use time_duration in the public interface and have the implementer provide a conversion to the platform specific structure. -- People/Hugo Duncan
Yes, that's what I (Jeff) had in mind. The key concept with time_duration is that it divides things into hours, minutes, seconds, and fractional seconds. How fractional seconds are specified is related to the resolution supported by the time_duration. So if microseconds is the finest resolution, we should be able to have the user specify times like:
time_duration td = seconds(1) + millisec(10) + microsec(20);
Then behind the interface we need to convert to a seconds and usec timestruct for the C api, so be it. I'm going to have to think a bit more about this, but we might be able to implement the underlying time_duration in terms of the time_val to minimize the conversion penalties (this kind of resolution splitting is currently done by one variant of the ptime class).
Perhaps it's better to separate the whole "time" stuff once and fo all...
For example a class boost::time, with some static methods like "now", default constructor "undefined time", iostream interface, string interface -- make it all thread safe and there's one hell of a usefull class. I see things like 'seconds' and 'minutes' like static (const) as well.
So:
using namespace boost;
time t = time::seconds * 10 + time::minute * 20; time n = time::now(); time future = n + t; thread.wait_untill(future); thread.wait(t);
.. and same for sockets.
The undefined state for 'time' is not as obvious... the point is that sometimes you want to threat 'time' as a condition (i.e. "if (t)" with "time t") - and if you do, what *is* the condition? Is it now? Is it in the past? I'd rather say it's "you have assigned time with a useful value".