API explosion (Re: [RFC/RFT] calloutng)
Luigi Rizzo
rizzo at iet.unipi.it
Wed Dec 19 15:09:28 UTC 2012
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
More information about the freebsd-current
mailing list