From owner-freebsd-current@FreeBSD.ORG Wed Dec 19 15:44:16 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFDA659C; Wed, 19 Dec 2012 15:44:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3428FC13; Wed, 19 Dec 2012 15:44:15 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qBJFi70F027414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 02:44:08 +1100 Date: Thu, 20 Dec 2012 02:44:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo Subject: Re: API explosion (Re: [RFC/RFT] calloutng) In-Reply-To: <20121219150809.GA98673@onelab2.iet.unipi.it> Message-ID: <20121220022926.C1961@besplex.bde.org> 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> <15882.1355914308@critter.freebsd.dk> <20121219150809.GA98673@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=EvuKNlgA c=1 sm=1 a=5xuQJAhXp8AA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=o_YUZdvV9usA:10 a=j58EWA6DYnG8U02EjcUA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 X-Mailman-Approved-At: Wed, 19 Dec 2012 16:51:10 +0000 Cc: Davide Italiano , Ian Lepore , Alexander Motin , Poul-Henning Kamp , freebsd-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:44:16 -0000 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