Question regarding lifetime of PRIV_TASK pointer

[Lee Hambley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20220323/ca2883c5/attachment.html>