Re: [boost] Comments about N2320

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-10-29 05:32:38

Jeff Garland wrote:
> Yuval Ronen wrote:
>> Hi,
>> After reading most of N2320, I have a few comments:
> 
>   ...snip several thoughts...
> 
>> * Time issues. To my eyes, it looks not pretty trying to get threading 
>> with time issues standardized before we have std::date_time. Making it a 
>> templated type not because we want genericity, but because we don't have 
>> the type we want yet, makes it look coerced. I think it's best to drop 
>> the time-related stuff, and add it properly together with date_time. 
>> Using the timed version of thread::join(), mutex::lock() and 
>> condition::wait() are very rare, and I think (hope) they can be 
>> implemented externally using native_handle().
> 
> A minimal subset of date-time *is* being added.  During the Kona meeting we 
> worked on unifying N2411 with N2320 to go into the working paper.  You can 
> read more about it at:
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2411.html
> 
> Basically allowing you to write code like:
> 
>   std::this_thread::sleep(std::seconds(1));
> 
>   Lock l;
>   std::condition::timed_wait(l, std::microseconds(100));
>   std::condition::timed_wait(l, std::milliseconds(100));
>   std::condition::timed_wait(l, std::nanoseconds(100));
>   std::condition::timed_wait(l, std::seconds(1));
> 
> etc.
> 
> The templatization of the time interfaces is at my request.  The primary 
> motivation is that 1) users/platform developers need the ability to create and 
> use their own time types (eg: picoseconds), and 2) unlike boost::date_time, 
> there is no "universal time_duration type" in the new proposals.  The history 
> on this is that I've been uncomfortable with the 'universal time_duration 
> type' for some time, but going without makes the date-time implementation 
> harder (more template magic) so it makes it less portable to older compilers. 
>   And with the backward compatibility issues, I haven't removed time_duration 
> from date-time yet.  Anyway, I'm uncomfortable with the time_duration type 
> because it locks you into an underlying representation with a particular size. 
>   While a 64 bit integers for these types work 95% of the time, there are 
> date-time users that compile the library using 96 bit internals b/c 64 isn't 
> enough for them.  However, the 'recompile the library' solution doesn't really 
> work for the standard.  So, a better option is to allow user extensibility and 
> eliminate the universal time duration.  That way if they want a 96 bit 
> picosecond type it's easy to create and use.

After reading that there is no universal time_duration type, I asked 
myself "then what is the return type of time_point subtraction?" So I 
looked in N2411, and saw that the answer is "nanoseconds". It also makes 
sense given the fact the utc_time is defined to have nanoseconds 
resolution. So my conclusion from it, is that nanoseconds /is/ that 
universal duration_time type. All the rest are (or can be) simple 
logic-less wrappers around nanoseconds. Had there wasn't any universal 
time point type (utc_time), but seconds_utc_time, nanoseconds_utc_time, 
etc, then you could say that there isn't a universal time, but as it is 
now, I think there is.

Now I also understand better the sentence that appear in N2320 in all 
timed functions: "ElapsedTime shall be explicitly convertible to 
nanoseconds". It's because nanoseconds are the basic for all. Now lets 
say you want to allow a demanding user to write his own picoseconds 
class. This class needs to be "explicitly convertible to nanoseconds". 
What does it mean? The only answer I can think of is "it has an explicit 
conversion operator to nanoseconds" (assuming C++0x have an explicit 
conversion operator feature). That makes the picoseconds class different 
from all the other time_duration types, because microseconds isn't 
explicitly convertible to milliseconds, for example. And there's 
probably a good reason it isn't convertible - because it looses 
resolution. So why should picoseconds be convertible to nanoseconds?

So it seems to me that threading timed function should accept the 
nanoseconds class. Any alleged picoseconds class will somehow have to 
support rounding-conversion to nanoseconds. Don't bother threading 
functions with that, let the picoseconds class handle it.