From owner-freebsd-arch@FreeBSD.ORG Wed Nov 29 10:45:34 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 3C35016A47B; Wed, 29 Nov 2006 10:45:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67B3F43CAD; Wed, 29 Nov 2006 10:45:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id D461D46DCA; Wed, 29 Nov 2006 05:45:30 -0500 (EST) Date: Wed, 29 Nov 2006 10:45:30 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200611281631.19224.jhb@freebsd.org> Message-ID: <20061129104205.C95096@fledge.watson.org> References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 10:45:34 -0000 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. Robert N M Watson Computer Laboratory University of Cambridge