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 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 <
> guillaume.quint...@gmail.com> 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
>> 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
>>> varnish-misc@varnish-cache.org
>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>
>>
___
varnish-misc mailing list
varnish-misc@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
