Date: Wed, 19 Dec 2012 16:08:09 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Davide Italiano <davide@freebsd.org>, 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: <20121219150809.GA98673@onelab2.iet.unipi.it> In-Reply-To: <15882.1355914308@critter.freebsd.dk> 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> <15882.1355914308@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 19, 2012 at 10:51:48AM +0000, Poul-Henning Kamp wrote: > -------- > 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) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121219150809.GA98673>