From owner-freebsd-arch@FreeBSD.ORG Wed Dec 19 10:51:50 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C300E28B; Wed, 19 Dec 2012 10:51:50 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBE48FC0C; Wed, 19 Dec 2012 10:51:50 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 15DB389EAF; Wed, 19 Dec 2012 10:51:49 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.5/8.14.5) with ESMTP id qBJApmOF015883; Wed, 19 Dec 2012 10:51:48 GMT (envelope-from phk@phk.freebsd.dk) To: Davide Italiano Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-reply-to: From: "Poul-Henning Kamp" 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> Date: Wed, 19 Dec 2012 10:51:48 +0000 Message-ID: <15882.1355914308@critter.freebsd.dk> Cc: Ian Lepore , Alexander Motin , phk@onelab2.iet.unipi.it, freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 10:51:50 -0000 -------- In message , 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.