From owner-freebsd-arch@FreeBSD.ORG Wed Nov 29 19:29:36 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org 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 65E3916A412; Wed, 29 Nov 2006 19:29:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F70443C9D; Wed, 29 Nov 2006 19:29:32 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kATJTJuD093331; Wed, 29 Nov 2006 14:29:30 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Robert Watson Date: Wed, 29 Nov 2006 13:46:00 -0500 User-Agent: KMail/1.9.1 References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org> <20061129104205.C95096@fledge.watson.org> In-Reply-To: <20061129104205.C95096@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611291346.01246.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 29 Nov 2006 14:29:31 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2258/Wed Nov 29 07:04:15 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: a proposed callout API X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2006 19:29:36 -0000 On Wednesday 29 November 2006 05:45, Robert Watson wrote: > On Tue, 28 Nov 2006, John Baldwin wrote: > > > One note and one question. First, the note. I was planning on rototilling > > our sleep() APIs to 1) handle multiple locking primitives, and 2) use > > explicit timescales rather than hz. I had intended on using microseconds > > with a negative value indicating a relative timeout (so an 'uptime' timeout, > > i.e. trigger X us from now) and a positive value indicating an absolute > > timeout (time_t-ish, and subject to ntp changes). Partly because (IIRC) > > Windows does something similar (negative: relative, positive: absolute, and > > in microseconds too IIRC) and Darwin as well. Part of the idea was to fix > > places that abused tsleep(..., 1), etc. to figure out a "real" sleep > > interval. With your proposal, I would probably change the various sleep > > routines to take a tick_t instead. That leads me to my question if if you > > would want to support the notion of absolute vs relative timeouts? > > I realize that Windows has established something of a convention here, but I > would prefer it if we had different APIs for absolute and relative timescales, > rather than overloading the signed value. I would instead like to either pass > in an unsigned value (giving compile-time checking, especially with gcc4), or > pass signed and assert it's > 0 in the relative case (to give runtime > checking). We could also generate run-time warnings for absolute times in the > past, and so on. Especially if we start to move towards rescheduling callouts > in order to reduce the size of the outstanding callout queues (TCP uses 4+ per > connection now, and 1 would be a better number), time offset arithmetic is > likely to be error prone, and catching these problems sooner rather than later > would be good. Different APIs would be fine. IIRC, that's how Darwin does it. With the tick_t idea, you could easily have: tick_t relative_wakeup(ulong nsec) tick_t absolute_wakeup(struct timeval *tv) (or something else, etc.) Doing it that way would let us stay as we are for now (just supporting the relative "uptime" timeouts) and investigate whether or not we want walltime timeouts (such as for TCP as Poul-Henning mentioned). I like tick_t, I just want to make sure we change foosleep() to use it as well, and wanted to raise the idea of relative vs absolute deadlines. -- John Baldwin