Assertion failure in VCL_DelBackend()

[Poul-Henning Kamp]

--------
In message <CABoVN9DM9bE45qkbhtsbCa5u6jnwNCfgK0QNAv1CH3XMrN4wEQ at mail.gmail.com>
, Dridi Boukelmoune 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, but if we're
>> serious about that, and if Varnish is liable to crash if a VMOD does
>> use them, then perhaps we should separate out the non-public
>> interfaces. Or at least document them as non-public -- we have that in
>> the *_int.h includes in vapi, for example.
>
>If it were up to me I'd simply remove everything that doesn't start
>with VRT_, except of course symbols from libvarnish* and related data
>structures :)

No.

The plan here is to offer two levels of API:

If you stick with VRT functions, porting your VMOD should be piece
of cake.

If you need to do something more advanced, you get what you ask for.

>I don't even know how you would delete the backend without breaking
>the type system.

That is *exactly* what I'm talking about.

When VCL types have underlying C types that require manual memory
management (ie: BLOB, BACKEND ...) we need to do manual memory
management, and we need to have a coherent and *understandable*
architecture for it.


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