Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2012 10:51:48 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Davide Italiano <davide@freebsd.org>
Cc:        Ian Lepore <freebsd@damnhippie.dyndns.org>, Alexander Motin <mav@freebsd.org>, phk@onelab2.iet.unipi.it, freebsd-current <freebsd-current@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: API explosion (Re: [RFC/RFT] calloutng)
Message-ID:  <15882.1355914308@critter.freebsd.dk>
In-Reply-To: <CACYV=-Eg542iHm9KfujPvCzZrA4TqepEBVA8RzT1YOHnCgfJnA@mail.gmail.com>
References:  <50CF88B9.6040004@FreeBSD.org> <20121218173643.GA94266@onelab2.iet.unipi.it> <50D0B00D.8090002@FreeBSD.org> <50D0E42B.6030605@FreeBSD.org> <20121218225823.GA96962@onelab2.iet.unipi.it> <1355873265.1198.183.camel@revolution.hippie.lan> <14604.1355910848@critter.freebsd.dk> <CACYV=-Eg542iHm9KfujPvCzZrA4TqepEBVA8RzT1YOHnCgfJnA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <CACYV=-Eg542iHm9KfujPvCzZrA4TqepEBVA8RzT1YOHnCgfJnA@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
phk@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15882.1355914308>