My pleasure! Just to show off a bit, and because I know you have an eye on rust: https://github.com/gquintard/varnish-rs/blob/main/examples/vmod_timestamp/src/lib.rs
VPriv (https://docs.rs/varnish/latest/varnish/vcl/vpriv/struct.VPriv.html) is the rust equivalent of vmod_priv and will properly be garbage-collected when dropped (yes, I do need to write some docs for it!) -- Guillaume Quintard On Thu, Mar 24, 2022 at 6:46 AM Lee Hambley <[email protected]> wrote: > Hi, > > This is exaclty what we were looking for. Thank you sincerely. > > Lee Hambley > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On Wed, 23 Mar 2022 at 17:15, Guillaume Quintard < > [email protected]> wrote: > >> Hi Lee, >> >> Looks like you had the right page, but missed the interesting part :-) In >> you >> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >> have this bit: >> >> > .fini will be called for a non-NULL .priv of the struct vmod_priv when >> the scope ends with that .priv pointer as its second argument besides a >> VRT_CTX. >> >> i.e. if your vmod_priv has a methods->fini pointer, it will be called >> when the vmod_priv is deleted. >> >> Was this what you were after, or did I misunderstand your question? >> >> -- >> Guillaume Quintard >> >> >> On Wed, Mar 23, 2022 at 7:28 AM Lee Hambley <[email protected]> >> wrote: >> >>> Dear List, >>> >>> I inherited a project using PRIV_TASK [1] for which the documentation >>> says: >>> >>> PRIV_TASK “per task” private pointers are useful for state that applies >>> to calls for either a specific request or a backend request. For instance >>> this can be the result of a parsed cookie specific to a client. Note that >>> PRIV_TASK contexts are separate for the client side and the backend >>> side, so use in vcl_backend_* will yield a different private pointer >>> from the one used on the client side. These private pointers live only for >>> the duration of their task. >>> >>> We do a form of reference counting in our internal data structures, and >>> the PRIV_TASK pointer in parts is used to hold a (counted) reference to >>> some data in the shared structure. >>> >>> We are struggling to find the latest possible safest place to hook where >>> PRIV_TASK is about to be invalid (end of the request) so that we can >>> safely, and finally decrement the reference count and clean-up. >>> >>> Writing this out now, I suspect that there's a safe exit from the state >>> machine [2] where we could modify our VCL to include a call to a clean-up >>> function in our vmod, however it's not clear to me if this would be "safe" >>> (restarts, request coalescing, etc, etc) >>> >>> In short then, is there an obvious place into which we can hook which is >>> the place where Varnish is already about to discard the "task" and it is >>> unoquivically safe for us to decrement our reference counted pointer to the >>> PRIV_TASK referenced data? >>> >>> Thanks so much, very much enjoying being in a role hacking on Varnish, >>> and Varnish adjacent stuff in my job currently. >>> >>> [1]: >>> https://varnish-cache.org/docs/trunk/reference/vmod.html#ref-vmod-private-pointers >>> [2]: >>> https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/#finite-state-machine >>> >>> >>> Lee Hambley >>> http://lee.hambley.name/ >>> +49 (0) 170 298 5667 >>> _______________________________________________ >>> varnish-misc mailing list >>> [email protected] >>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >>> >>
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
