New "timeout" api, to replace callout

[Luigi Rizzo]

On Sun, Dec 02, 2007 at 03:08:41PM +0000, Poul-Henning Kamp wrote:
> In message <20071202055031.A8107 at 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