API explosion (Re: [RFC/RFT] calloutng)

[Alexander Motin]

On 19.12.2012 12:03, Davide Italiano wrote:
> On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>> --------
>> In message <1355873265.1198.183.camel at revolution.hippie.lan>, Ian Lepore writes
>> :
>>> On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
>>
>>> I'm not so sure about the 2^k precision.  You speak of seconds, but I
>>> would be worrying about sub-second precision in my work.
>>
>> It is a bad idea, and it is physically pointless, given the stabilities
>> of the timebases available for computers in general.
>>
>> Please just take my word as a time-nut, and use a 32.32 binary format
>> in seconds (see previous email) and be done with it.
>
> Right now -- the precision is specified in 'bintime', which is a binary number.
> It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in
> the specific platform.
> I do not really think it worth to create another structure for
> handling time (e.g. struct bintime32), as it will lead to code
> duplication for all the basic conversion/math operation. On the other
> hand, 32.32 may not be enough in the long future.
> What do you think about that?

Linux uses 32.32 format in their eventtimers code. Respecting that now 
we have no any timer hardware with frequency about 4GHz, that precision 
is probably sufficient. But if at some point we want to be able to 
handle absolute wall time, then 32bit integer part may be not enough. 
Then we return to the question: "how many different data types do we 
want to see in one subsystem"? Sure, using single 64bit value would be 
much easier then struct bintime from many perspectives, but what's about 
the edge cases?

-- 
Alexander Motin