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 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
