Assertion failure in VCL_DelBackend()

Geoff Simmons geoff at uplex.de
Mon Nov 16 12:39:25 CET 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/16/2015 10:55 AM, Poul-Henning Kamp wrote:
> 
> One of my background-tasks is to put the "hands-off!" items in 
> clearly marked #include files.

OK

> It's monday morning. [...]

All good. I can go with what's possible at the moment. Get well.

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

FWIW, the VMODs I have in mind are all based around the idea that
backends are owned by VCL, which defines their lifetime, unless you
explicitly delete them before the VCL is discarded.

(Now that you mention it, though, it would be quite useful for our use
case to let them live on until the child process dies ...)

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

Well OK, but is there really a use case for backends with anything
shorter than PRIV_VCL lifetime? Backends that live and die during a
task or a top request ... that sounds pretty far out to me. And I
can't even picture what PRIV_CALL for a backend would mean.


Best,
Geoff
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Scheffelstraße 32
22301 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWScBtAAoJEOUwvh9pJNURwdAQAIgL/PQCazVsVVcQhDBCPBh+
HnPMv2JJNCpAQ5X3QKe5VFgVI9BqFooRvUTpG7/U2r8vMwBcEPExc6nX+wyFIcdZ
WhJwxgUTT5WIAP8g5Nj4vMZvM0Ay/0XaCVX1VhmjNIawdiOXfjjabLRYVsBzz87C
sX170Z2j8hMWvAgdREVAbIY4nTZWolGQvdzK2aul7+oPt9UblIsmPdnDV+w5w27A
9EiwQbUV0MKxMicSdL1F6aYRBKAZB0HOcbxrRkI3R0g8PUxpzz4UgBKBRZD08WRj
nhjOjwl4b3tTQVhi/AvZBz/TM25eijVlWDi/3DIy4vviejKnVs+UKWuG5Mdgzogr
nw07nMRDG+4QMSFazriVxwYaf7q0HmjoNenRQ9xRm0R7lntlYjJDQPgVIyb2daDI
mcOy80axNyvyI5VO2dWcr7/H/0v3JqMOpqMeDjMrYjOyy5d3tSXvLsndcS2t1Uti
5mEpIi6mCeAR++NQn77cTyuFkz/T6Hod6Jj0lr+SQhEEFxn4yS1UJkpkgSqoOzGn
Lg20OVVr7BOJ+ZH9SEkyQ2f7tz4iVxqIM/ao5Uie9BlZ5S9MIBrZJApXQqJJdA6n
249ZqChQV9zSfX+51LLRp5cOKSjPBNkaDSz6LeDmAQqJaJ2cmCKGkuk+Yr0+fqzL
6N4kPi7SB5XoCOxN5/3w
=1/S5
-----END PGP SIGNATURE-----



More information about the varnish-dev mailing list