Questions on backend allocations

[Poul-Henning Kamp]

--------

I've been pop'ing stack and come back down to this old topic.

The current hurdle is the cold/warm VCL events and how they get
communicated to VMODS, directors and backends, and possibly other
thingmajicks as well.

It is very important to remember here, that backends is a subtype
of directors, and that what the VMOD would do is create dynamic
directors (which happen to be backends).

Broadly speaking one avenue is to register all directors on a
list of the VCL, and tell them warm/cold via this list.

Right now we do not register directors anywhere, they are free
standing objects and can come and go as they please.

Making it mandatory to register all directors, just so we can
send them events they probably don't care about seems rather
silly.

The alternative way is to make cold/warm events independent and
provide a "call this function with this argument" registration
mechanism for any interested temperature-sensitive vmod, object,
backend or doodad.

The disadvantage to this model is that there is no obvious
or natural order to call these call-back functions.

For instance we could waste time sending "COLD" to a bunch of
backends which did individual registrations, on to see the vmod
destroying them all when it gets the COLD event.

Calling in first-registered-first-called order would probably
avoid that scenario and give some kind of predictability.

This ordering insecurity will require some thinking in some VMODs
I can think of, but I can't think of any VMOD for which there
isn't a reasonable solution.

So I'm currently leaning towards this model.

Backends should obviously register to get the events (in
cache_backend_cfg), no matter if they are static or dynamic,
so VMODs won't need to propagate the events.

The third option is to make the vmod_priv the "base object"
in compiled VCL, and tell those instead.  This has a lot of
merit from many angles, but I think that would have to wait
for 5.0.



-- 
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.