Re: [boost] Comments about N2320

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-10-28 16:02:31

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.

Jeff