API explosion (Re: [RFC/RFT] calloutng)
Bruce Evans
brde at optusnet.com.au
Wed Dec 19 15:44:16 UTC 2012
I finally remembered to remove the .it phk :-).
On Wed, 19 Dec 2012, Luigi Rizzo wrote:
> On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote:
>> ...
>> 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 :)
Er, he was careful. DURNSEC gives 4, not 0. This is not very accurate,
but probably good enough.
Your version without parentheses is not so careful and depends on
a magic order of operations and no overflow from this. E.g.:
500*DURNSEC = 500*DURSEC / 1000000000 = 500*((dur_t)1 << 32) / 1000000000
This is very accurate and happens not to overflow. But 5 seconds represented
a little strangely in nanoseconds would overflow:
5000000000*DURNSEC = 5000000000*((dur_t)1 << 32) / 1000000000
So would 5 billion times DURSEC, but 5 billion seconds is more unreasobable
than 5 billion nanoseconds and the format just can't represent that.
>
> (btw the typedef is swapped, should be "typedef int64_t dur_t")
Didn't notice this.
Bruce
More information about the freebsd-arch
mailing list