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.