a proposed callout API

[John Baldwin]

On Thursday 30 November 2006 09:52, Ivan Voras wrote:
> Poul-Henning Kamp wrote:
> > In message <200611292147.kATLll4m048223 at apollo.backplane.com>, Matthew 
Dillon w
> > rites:
> > 
> >>    The difference between you and me, Poul, is that you always try to 
play
> >>    cute tricks with words when you intend to insult someone.  Me? I just
> >>    go ahead and insult them explicitly.
> > 
> > I can do that too:  You're a pompous asshole who doesn't know what
> > you're talking about.
> > 
> > Now, does that make you feel better ?
> > 
> >>    In anycase, I think the relevance of my comments is clear to anyone 
who
> >>    has followed the project.  Are you guys so stuck up on performance
> >>    that you are willing to seriously pollute your APIs just to get rid of
> >>    a few multiplications and divisions?
> > 
> > You have your project and we have ours.
> > 
> > You make your choices, we make ours.
> > 
> > You have your mailing lists, we have ours.
> > 
> > CTRL-D for all I care.
> 
> No trying to take sides here, but for us willing to learn here, what
> exactly are the problems in Matt Dillon's suggestions? From a novice's
> POV, having per-cpu queues looks (emphasis: looks) very scalable and
> performant.

I don't think phk@ is ruling out per-cpu callout wheels.  I know it is 
something I've thought about myself for a while now.  One of the goals of the 
change is to make things a bit more abstract and less tick-centric (i.e. 
specify timeouts in real time units like nanoseconds or seconds rather than 
tick counts based on a hz periodic timer).  Whether or not there are per-cpu 
callouts is really an implementation detail rather than an API one.

-- 
John Baldwin