Re: [boost] Time interfaces threads/file (was Design for a file system library)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-25 13:50:14

At 11:43 AM 2/25/2002, Jeff Garland wrote:

 >> -----Original Message-----
 >> From: Beman Dawes [mailto:bdawes_at_[hidden]]
 >> I guess what I'm saying is that at least two potential Boost libraries
 >> (threads and filesystems) need some notion of time that goes beyond
 >> anything now in the standard, so we really need a Boost-now and
 >> standard-later solution so developers don't have to keep reinventing 
the
 >> wheel.
 >
 >
 >I agree.  Since GDTL supports the concept of multiple time systems for
 >different
 >purposes, I'd like to gather the specific requirements for threads and
 >filesystems.  Here's what I see from the current file discussion and the
 >current
 >threads library:
 >
 >* represent time durations (eg: 01:02:03.0000001) (thread only)
 >* convert durations to counts a different resolutions (micro, nano, etc)
 >(thread
 >only)
 >* represent time points  (eg: 2002-02-25 08:00:00.0000001) (both)
 >* represent time points with resolutions down to nano-seconds (both)

A suggestion: figure out the maximum resolution any (actual, not 
theoretical) current system will need.  Then assume Moore's law has quite a 
bit of life left.  Adjust accordingly.  If that means nano-seconds, fine, 
but it is obvious in 15-years that pico-seconds will be needed, make 
allowances now.

 >* provisions for platforms that don't support nano-seconds (both)
 >* get the current time point from the clock (both)
 >* add durations to a time point (thread only)
 >* compare timepoints  (eg: > < == !=) (both)
 >* compare durations   (eg: > < == !=) (thread only)
 >* ability output a time point to a string (file only -- clients)
 >* a desire to minimize the dependencies
 >
 >Some things you DON'T need:
 >* ability to represent time points prior to 1970

OK, I guess.  Another question to ask yourself is how far do you want a 
filesystem (or less likely, a thread) to last?  In other words, when does 
roll-over occur going forward?  I'd assume a couple of hundred years on the 
theory a file might really last 50 years, but you should then add a big 
fudge factor to stifle endless arguments about what the exact number should 
be.

 >* ability to represent 'special values': not-a-time, infinities
 >* ability to output time durations to string (except maybe for debugging)
 >* ability to parse a string and build a time point or duration

Looks good,

--Beman