[RFC] callout overhaul: part I

[Poul-Henning Kamp]

In message <3bbf2fe10711081135y3473817ejbc72574e3e8c763d at mail.gmail.com>, "Atti
lio Rao" writes:

First I'd like to thank you for doing something about this Attilio,
I havn't had time for it recently.

You are right in many of the points you make, RETURNUNLOCKED, different
kinds of locks etc, and we should integrate that into my API proposal.

You are also wrong in some places, and I'd like to discuss those.

1.  About the name
------------------

In my proposal I used a generic XXX_ prefix, because nailing the
name was not the bikeshed I wanted to paint.

You have chosen "callout" but I'm not sure I like that very much,
this is not really a callout facility, it is a timer facility.

I don't like when core APIs have silly long names, that clutters
up source code needlessly, so my preference would probably be
to use a short prefix, something like "tmr", "when", "wake" or
similar.

But let's take that offline and not start a bikeshed here.

2.  About XXX_instances
-----------------------

You propose a XXX_arm() and a XXX_arm_cpu().  That is a pointless
limitation.

My API proposal said specifically:

> The functions above will actually be wrappers for a more generic
> set of the same family, which also takes a pointer to a callout-group.

And I guess the meaning of this was too subtle, so I will elaborate:

The fundamental function will be called

	XXX_arm_cg(struct xxx_group *cg, ...)

The xxx_group argument can be NULL, in which case a group is
chosen for you by unspecified means.

	XXX_arm(...)

Is a macro wrapper that calls the above with a NULL argument,
and we can make

	XXX_arm_cpu(...)

call it with an argument of pcpu->callout_group if we like.

But we do not want to limit ourselves to only those two options,
for intance we may find it a benefit later to put long running
non-likely callouts in their own group, optimized for such behaviour.

(And we cannot settle the group earlier than xxx_arm() if we
want to have the per-cpu option, so xxx_init() can't do it)

3. Two stage conversion
-----------------------

You propose a two-stage conversion.  That is a bad idea when we
can do it as efficiently with a one-stage conversion.

Having thought a bit more about the conversion, I think the right
way to do this is parallel implementations:  Lets add the new
API and start converting critical code to use it.

We may have to retain the old callout-wheel for a couple of releases
for compat reasons anyway, and I'm not convinced that it is sensible
to emulate the old API with the new, the cost in calculations and
memory management may be too high.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.