-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 11/04/2015 11:58 AM, Poul-Henning Kamp wrote:
> --------
>
> Ok, wrapping this subject up:
>
> Right now PRIV_foo is named with a mix of lifetime and visibility,
> and we seem to need to be able to control both aspects.
>
> The easiest and most backward compatible, seems to be to make the
> naming
>
> PRIV_lifetime[_visibility]
>
> With a default visibility of "VMOD" with other possible values
> being "CALL" and "OBJ"
>
> Three of the the current four PRIV's maps naturally:
>
> PRIV_VCL -> PRIV_VCL_VMOD PRIV_TOP -> PRIV_TOP_VMOD PRIV_TASK ->
> PRIV_TASK_VMOD
>
> But:
>
> PRIV_CALL -> PRIV_VCL_CALL
>
> The functionality Geoff requires would be PRIV_TASK_OBJ
>
> If we special-case PRIV_CALL, this is backwards compatible.
>
> Comments ?
Sounds like the right solution. If you can indulge me for a few
minutes, I'd like to try re-phrasing it, to make sure we all
understand the same thing. It gets a long-winded further down, because
I want to go through all of the permutations.
3 lifetimes * 3 visibilities mean that we'll have 9 PRIV scopes, more
than twice of what we have now. That will make documentation to aid
VMOD authors important, so this will also be a kind of first draft for
that (unless of course I'm getting it all wrong).
For practical purposes, the VMOD author will need to know:
- - When can the scope be used at all (priv != NULL)
- - When is the priv object new (when will priv->priv == NULL)
- - When will it be destroyed (when is priv->free called)
- - Under what circumstances will a function/method declaring a
parameter with this scope see the same object, either in another
function/method call from the same VMOD interface, in the same VCL, or
in another thread.
PRIV_{lifetime}_* controls the second and third conditions, and
PRIV_*_{visibility} controls the last one.
Is PRIV_*_OBJ legal for function declarations? My guess is no, and
that and that priv==NULL for PRIV_*_OBJ in any context that is not an
object method or init/free function.
(Actually, I think it would be best if generate.py would reject
illegal scopes in the first place, by declining to generate vcc_if.*.
But we presently have priv==NULL in backend contexts for PRIV_TOP, so
I'll just assume that priv==NULL for PRIV_*_OBJ in function calls as
well.)
Also not clear to me -- do PRIV_TOP_* and PRIV_TASK_* extend
visibility over restarts and retries? So if I allocate resources for a
PRIV_TOP_* or PRIV_TASK_* scope during a client request, and there's a
restart, will I see the same resources after the restart? And the same
question for PRIV_TASK_* and retries in backend threads.
I'm guessing that the answer is yes in both cases (at least that's
what makes sense to me).
So for the 9 scopes, this is what I come up with:
PRIV_VCL_VMOD (== current PRIV_VCL)
- - new when called the first time for any func/method in the VMOD
interface after the VCL is loaded
- - destroyed when the VCL is unloaded
- - the same for any func/method in the interface, in any thread, using
the scope during the lifetime of a VCL
- - the same object is passed into a VMOD's event function
PRIV_TOP_VMOD (== PRIV_TOP)
- - new when called the first time by any func/method during a client
request
- - destroyed when the client request is completed
- - the same for any func/method in the interface during a client
request and its ESI subrequests, including after restarts
- - different for different client requests/subrequests (in different
threads)
- - priv==NULL always for backend threads
PRIV_TASK_VMOD (== PRIV_TASK)
- - new when called the first time by any func/method during a client or
backend task
- - destroyed when the client/backend task is completed
- - the same for any func/method in the interface during the same c/b
task, including after restarts and retries
- - different in calls during different c/b tasks (in different threads)
PRIV_VCL_CALL (== PRIV_CALL)
- - new when invoked the first time by any distinct VCL statement after
the VCL is loaded
- - destroyed when the VCL is unloaded
- - the same for that particular call, in any thread, during the
lifetime of VCL
- - different for any other invocation, i.e. by a different VCL
statement, even of the same func/method
PRIV_TOP_CALL
- - new when invoked by a VCL statement during a client request
- - destroyed when the client request is completed
- - the same for that invocation during any ESI subrequest, and after
restarts
- - different for other client requests/subrequests, and for other
invocations of the same func/method
- - priv==NULL in backend threads
PRIV_TASK_CALL
- - new when invoked by a VCL statement during a client or backend task
- - destroyed when the client/backend task is completed
- - for the client side: the same for that invocation during any ESI
subrequest, and after restarts
- - backend side: the same for that invocation after retries
- - different for any other invocation (even of the same func/method)
- - If I'm seeing this right, the usefulness would be to preserve
information for one call over restarts or retries.
PRIV_VCL_OBJ
- - new when called the first time for any method of a specific object
after the VCL is loaded
- - destroyed when the VCL is unloaded
- - the same for any method call of that object, in any thread, during
the lifetime of a VCL
- - priv==NULL for functions
PRIV_TOP_OBJ
- - new when called the first time for any method of a specific object
during a client request
- - destroyed when the client request is completed
- - the same for that object during the client request and its
subrequests, and after restarts
- - different for other client requests/subrequests, and for different
objects
- - priv==NULL for backend threads and functions
PRIV_TASK_OBJ
- - new when called the first time for a specific object during a client
or backend task
- - destroyed when the client/backend task is completed
- - the same for that object during that task, including ESI subrequests
and after restarts on the client side, and after retries on the
backend side
- - different for different objects, and for different c/b tasks in
different threads
- - priv==NULL for functions
Sorry for another long email, and/or if I got it all wrong. I do think
we'll eventually need to understand and document the 9 scopes at this
level of detail.
Best,
Geoff
- --
** * * UPLEX - Nils Goroll Systemoptimierung
Scheffelstraße 32
22301 Hamburg
Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753
http://uplex.de -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWTwThAAoJEOUwvh9pJNUR6mUQAJXMPurMZ84uy7UgsDFBl24Y
m7dfqENa+J7tsO4VLwBR5OJM4Z3T5rk+gBks6t9RI+P+53aPIeBbZNHdbCGZOIDD
jIAfVRSt38nW6nYeuU4/5v0pNFI3zeM7p4AOviqc6K3MOWe+dVSGN3S0pTJ+e5qC
2/QlEj2NmQJwfXaqL0I8zHfad2v5syDLKPmsfs60vooyUFsPRc4jyGpYAMNu5Y/a
uS2H2hK1XpmKMcz1urKz5k4FbqpCYl/2DaoyRWSWBxav79LwLaNaBeDkrTGdU5Iu
vbTjxQpp+de5w/AJ6zpi9bz+iCGiPflSNFzdnUhPpsA86SxeWHT0JZQsD11/ikho
emaUU7u5DarWlquHhcqF6HFFOzS8LRRO1UMFceu1Apj5YhrtGlDMGU0SWTQ+KsS4
Pyx4QejKHB/L2I9OoLFO1bl3yP2xoscoTHmW0d9Lmxtx2yuAN1CHAfcq3nSgvXcH
wB2KoUEFIpjV3OUlyQvfjOXJdIVApDVyG3fpEXyo6cB3mGGtwfRE4XThhG2g7ZxX
osOGGUsYLEi9O+0sCgG7JZkxTlWqgXBgu7Sqb3jSr/YXX6BspfrYBE+7OLg/6zlT
oOLrwrtke3+mCJvJGvXtTiDs0x3eFy6YFc6uX4SA4LF8k7tadlEvvo2twzW5R8r4
WChNwb5Rxn+PQZfvxhh0
=Mo4h
-----END PGP SIGNATURE-----
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
trac_1800.patch (9.30 KB)