From owner-freebsd-arch@FreeBSD.ORG Sun Dec 2 15:34:52 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 3FD3916A419 for ; Sun, 2 Dec 2007 15:34:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0180513C448 for ; Sun, 2 Dec 2007 15:34:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 6DA9917105; Sun, 2 Dec 2007 15:34:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id lB2FYnEk019519; Sun, 2 Dec 2007 15:34:49 GMT (envelope-from phk@critter.freebsd.dk) To: Luigi Rizzo From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 02 Dec 2007 07:26:58 PST." <20071202072658.A9217@xorpc.icir.org> Date: Sun, 02 Dec 2007 15:34:49 +0000 Message-ID: <19518.1196609689@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 15:34:52 -0000 In message <20071202072658.A9217@xorpc.icir.org>, Luigi Rizzo writes: >On Sun, Dec 02, 2007 at 03:08:41PM +0000, Poul-Henning Kamp wrote: >> Using a deadline timer based in the HPET, the timeout can be scheduled >> to any 1/14318181th of a second > >This must obviously come for a price or there would be no reason to >provide 'millisecond' and 'second' precisions that you suggested. >I agree that the API should not assume that the hardware is based on >a periodic timer, but in the same way it should not assume that >the hardware can generate arbitrary timeouts. If the client code needs this finegrained control, the trick is to extend the API to be able to provide this information somehow. But before designing that, we need to have concrete examples to talk about. >"periodically with whatever period is convenient to you" is >a legitimate request that client code might have. >(I understand that this concept of time is very southern european :) I disagree, that case, should be "with a period between N and M, at your choice". And yes, it may be that we need to extend the API for that, but please give a concrete example so we know what we're talking about. >It wouldn't make sense to do poll-based event handling at the same >rate on a 133MHz soekris or on a 3 GHz multicore cpu. Hz is the same for those two, so today we poll at the same rate. >In any case: in terms of API it costs absolutely nothing to support >system-dependent resolutions instead of absolute ones, so >i don't quite understand the opposition. I'm applying Jim Gettys 3. rule from the X11 project: 3.The only thing worse than generalizing from one example is generalizing from no examples at all. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.