Hi Guillaume, Our problem is solved thanks to `methods` and cleanup (and the magic of `Arc<T>`)
Thanks so much the `struct.VPriv` looks very interesting, unfortuantely with our homebrew, ad-hoc bindings it's nothing we can profit from right away, but it's very nicely done, thanks for sharing. Cheers, and have a good day. Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 On Thu, 24 Mar 2022 at 19:32, Guillaume Quintard < [email protected]> wrote: > 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
