From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 19:06:40 2007 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A1E16A418 for ; Sun, 2 Dec 2007 19:06:40 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.freebsd.org (Postfix) with ESMTP id 182F013C455 for ; Sun, 2 Dec 2007 19:06:40 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id lB2J5MBW022665; Sun, 2 Dec 2007 11:05:22 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id lB2J5MBO022664; Sun, 2 Dec 2007 11:05:22 -0800 (PST) (envelope-from rizzo) Date: Sun, 2 Dec 2007 11:05:22 -0800 From: Luigi Rizzo To: Poul-Henning Kamp Message-ID: <20071202110522.A22571@xorpc.icir.org> References: <20071202.093603.228972203.imp@bsdimp.com> <45308.1196617434@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45308.1196617434@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sun, Dec 02, 2007 at 05:43:54PM +0000 Cc: arch@FreeBSD.org Subject: Re: New "timeout" api, to replace callout 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: Sun, 02 Dec 2007 19:06:40 -0000 On Sun, Dec 02, 2007 at 05:43:54PM +0000, Poul-Henning Kamp wrote: > In message <20071202.093603.228972203.imp@bsdimp.com>, "M. Warner Losh" writes: > >In message: <19827.1196612123@critter.freebsd.dk> > > "Poul-Henning Kamp" writes: > >: In message <20071202.085545.177225588.imp@bsdimp.com>, "M. Warner Losh" writes: > >: > >: >There are a number of places in the tree that use a parameter of '1' > >: >today to mean "next time that's convenient." Some of these places are > >: >clever and know that HZ is never < 100 or > 1000 (or so they think), > >: >while others are just sloppy code. > >: > >: Yes, but those can hardly be called "concrete" in terms of wanting > >: to know what they mean, can they ? :-) > >: > >: The only way I can see we can deal with them in the short term, > >: is to ask for timeouts of "1000000 / hz, TIMEOUT_USEC" > > > >Or have a "timeout_soon" function like you have the other timeout > >conversion routines. > > I'm not very keen on offering too much rope. > > Intelligent decisions need to be made about these polling rates and > making it too easy to not think about it would be to encourage > bad practices. the approach 'no less than N, preferably* no more than M' {n|u|m}seconds that phk suggested looks to me like the correct approach. The programmer can make his assumptions explicit, and the system can make convenient decisions without making arbitrary assumptions. cheers luigi