Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Dec 2007 07:26:58 -0800
From:      Luigi Rizzo <rizzo@icir.org>
To:        Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc:        arch@freebsd.org
Subject:   Re: New "timeout" api, to replace callout
Message-ID:  <20071202072658.A9217@xorpc.icir.org>
In-Reply-To: <19256.1196608121@critter.freebsd.dk>; from phk@phk.freebsd.dk on Sun, Dec 02, 2007 at 03:08:41PM %2B0000
References:  <20071202055031.A8107@xorpc.icir.org> <19256.1196608121@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 02, 2007 at 03:08:41PM +0000, Poul-Henning Kamp wrote:
> In message <20071202055031.A8107@xorpc.icir.org>, Luigi Rizzo writes:
> 
> 
> >This is why i suggest having a 'scale' that can represent '1 tick'
> >(and also don't depend on TIMEOUT_MSEC == 1000 and so on, but keep
> >them opaque and require that the client code uses one of the supported
> >scales).
> 
> 
> 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.

Secondy:

>                                 and there will be no concept of "a
> tick" as we know it now.

> Clients should say how often they want to be called, and they should
> express it in terms of time, not based on some implementation detail
> of a historical implementation of the scheduler.

"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 :)

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.
Even if you kick HZ out of your API, it will come back
in some indirect form.

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.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071202072658.A9217>