Mailing List Archive

Question regarding lifetime of PRIV_TASK pointer
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
Re: Question regarding lifetime of PRIV_TASK pointer [ In reply to ]
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@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@varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
Re: Question regarding lifetime of PRIV_TASK pointer [ In reply to ]
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@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@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@varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
Re: Question regarding lifetime of PRIV_TASK pointer [ In reply to ]
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@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@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@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@varnish-cache.org
>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>
>>
Re: Question regarding lifetime of PRIV_TASK pointer [ In reply to ]
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@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@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@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@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@varnish-cache.org
>>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>>
>>>