a proposed callout API

[John Polstra]

On 13-Nov-2006 Poul-Henning Kamp wrote:
> 
> A number of problems have been identified with our current callout
> code and I have been thinking about and discussed various aspects
> with people during the EuroBSDcon2007 conference.
> 
> A lot of people are interested in this, so here is a quick sketch
> of what I'm thinking about:
> 
> 
> The Problems
> ------------
> 
> 1. We need better resolution than a periodic "hz" clock can give us.
>    Highspeed networking, gaming servers and other real-time apps want
>    this.
> 
> 2. We "pollute" our call-wheel with tons of callouts that we know are
>    unlikely to happen.
> 
> 3. We have many operations on the callout wheel because certain
>    callouts gets rearmed for later in the future.  (TCP keepalives).
> 
> 4. We execute all callouts on one CPU only.
> 
> 5. Most of the specified timeouts are bogus, because of the imprecision
>    inheret in the current 1/hz method of scheduling them.
> 
> and a number of other issues.
> 
> 
> The proposed API
> ----------------

I like the proposed API.  FWIW, the problems you listed that are
most important to me are #4 and #1.  Inexpensive automatic rearming
for periodic timeouts is also important.

John