From owner-freebsd-arch@FreeBSD.ORG Sat Dec 22 22:50:28 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 9802952C; Sat, 22 Dec 2012 22:50:28 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 298398FC0A; Sat, 22 Dec 2012 22:50:26 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5F7793592D9; Sat, 22 Dec 2012 23:50:25 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 479B62848C; Sat, 22 Dec 2012 23:50:25 +0100 (CET) Date: Sat, 22 Dec 2012 23:50:25 +0100 From: Jilles Tjoelker To: Poul-Henning Kamp Subject: Re: API explosion (Re: [RFC/RFT] calloutng) Message-ID: <20121222225025.GA46583@stack.nl> 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> <50D192E8.3020704@FreeBSD.org> <15947.1355914806@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15947.1355914806@critter.freebsd.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Davide Italiano , Ian Lepore , Alexander Motin , 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: Sat, 22 Dec 2012 22:50:28 -0000 On Wed, Dec 19, 2012 at 11:00:06AM +0000, Poul-Henning Kamp wrote: > -------- > In message <50D192E8.3020704@FreeBSD.org>, Alexander Motin writes: > >Linux uses 32.32 format in their eventtimers code. > (And that is no accident, I know who they got the number from :-) > >But if at some point we want to be able to > >handle absolute wall time, [...] > Then you have other problems, including but not limited to clock > being stepped, leap-seconds, suspend/resume and frequency stability. > If you want to support callouts of the type ("At 14:00 UTC tomorrow") > (disregarding the time-zone issue), you need to catch all significant > changes to our UTC estimate and recalibrate your callout based on > that. > It is not obvious that we have applications for such an API that > warrant the complexity. > Either way, such a facility should be layered on top of the callout > facility, which should always run in "elapsed time"[1] with no attention > paid to what NTPD might do to the UTC estimate. POSIX specifies functions that assume such a facility exists, although applications may not care much if we implement them incorrectly. For example, pthread_mutex_timedlock() and sem_timedwait() shall time out when the CLOCK_REALTIME clock reaches the given value, and pthread_cond_timedwait() and clock_nanosleep() (with TIMER_ABSTIME) shall time out when the specified clock reaches the given value. > So summary: 32.32 is the right format. > Poul-Henning > [1] Notice that "elapsed time" needs a firm definition with respect > to suspend/resume, and that this decision has big implications > for the API use and code duplication. > I think it prudent to specify a flag to callouts, to tell what > should happen on suspend/resume, something like: > SR_CANCEL /* Cancel the callout on S/R */ > /* no flag* /* Toll this callout only when system is running */ > SR_IGNORE /* Toll suspended time from callout */ > If you get this right, callouts from device drivers will just "DTRT", > if you get it wrong, all device drivers will need boilerplate code > to handle S/R Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC vs CLOCK_UPTIME. -- Jilles Tjoelker