Question regarding lifetime of PRIV_TASK pointer

[Lee Hambley]

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 <
guillaume.quintard at gmail.com> 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 <lee.hambley at gmail.com> 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.quintard at 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 <lee.hambley at gmail.com>
>>> 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 at varnish-cache.org
>>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20220330/6fecce46/attachment-0001.html>