Assertion failure in VCL_DelBackend()

Poul-Henning Kamp phk at phk.freebsd.dk
Mon Nov 16 10:55:54 CET 2015


--------
In message <5649A162.104 at uplex.de>, Geoff Simmons writes:

> VCL_DelBackend is declared in $include_dir/cache/cache_backend.h, so
> it's available to a VMOD, and there's no indication that it's "not
> supposed to" be used. I've suspected that there are things in
> $include_dir that aren't really meant to be public,

One of my background-tasks is to put the "hands-off!" items in
clearly marked #include files.

cache/cache_priv.h is the first part of that.

> But it would be a real letdown if VCL_DelBackend is made unavailable
> with no replacement for removing backends. I don't see any other
> current interface that can do it.

It's monday morning.

Power has been out twice already.

I was down with a flu-ish infection for the last five days and my
brain only started working again yesterday.

So I can't give you a definitive VCL_DelBackend() answer right now.

But what I will say, is that we have a general object-lifetime
issue, which so far is related to both VMOD_PRIV's and backends,
and it is complicated.

One example is:

	if (foomod.get_me_a_new_backend() == backend_1) {
		// do something
	}

How long does that backend live ?

Who decides ? - and how ?

What about

	if (amod.get_blob() == bmod.get_blob()) {
		// do something
	}

How long time does those blobs live ?

My current thinking is what I outlined last week(?) about VMOD_PRIV,
that VMODs will have to become explicit about this.

If we do that and make backends (ie: directors) VMOD_PRIV's, then
a VMOD would be able to create a backend and mark it for deletion
when the transaction dies, and have it happen automatically.

That widget may not be a VMOD_PRIV anymore, but rather a "VMOD_OBJ"
which has a "Interface Spec" ("I'm a director") and a "Method-Vector"
(the ->getfd(), ->gethdr() C-functions etc.)

Needless to say that is not back-portable 4.x stuff.

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



More information about the varnish-dev mailing list