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

On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote:
> --------
> In message <CACYV=-Eg542iHm9KfujPvCzZrA4TqepEBVA8RzT1YOHnCgfJnA_at_mail.gmail.com>
> , Davide Italiano writes:
> 
> >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.
> 
> And that is way overkill for specifying a callout, at best your clock
> has short term stabilities approaching 1e-8, but likely as bad as 1e-6.
> 
> (The reason why bintime is important for timekeeping is that we
> accumulate timeintervals approx 1e3 times a second, so the rounding
> error has to be much smaller than the short term stability in order
> to not dominate)
> 
> >I do not really think it worth to create another structure for
> >handling time (e.g. struct bintime32), as it will lead to code
> 
> No, that was exactly my point:  It should be an integer so that
> comparisons and arithmetic is trivial.   A 32.32 format fits
> nicely into a int64_t which is readily available in the language.
> 
> As I said in my previous email:
> 
> 
>         typedef dur_t   int64_t;        /* signed for bug catching */
>         #define DURSEC  ((dur_t)1 << 32)
>         #define DURMIN  (DURSEC * 60)
>         #define DURMSEC (DURSEC / 1000)
>         #define DURUSEC (DURSEC / 10000000)
>         #define DURNSEC (DURSEC / 10000000000)
> 
> (Bikeshed the names at your convenience)
> 
> Then you can say
> 
> 	callout_foo(34 * DURSEC)
> 	callout_foo(2400 * DURMSEC)
> or 
> 	callout_foo(500 * DURNSEC)

only thing, we must be careful with the parentheses

For instance, in your macro, DURNSEC evaluates to 0 and so
does any multiple of it.
We should define them as

#define DURNSEC DURSEC / 10000000000
...

so DURNSEC is still 0 and 500*DURNSEC gives 214

I am curious that Bruce did not mention this :)

(btw the typedef is swapped, should be "typedef int64_t dur_t")

cheers
luigi