--------
In message <CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@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)
With this format you can specify callouts 68 years into the future
with quarter nanosecond resolution, and you can trivially and
efficiently compare dur_t's with
if (d1 < d2)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
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"
