Thoughs on VMODs and VCL

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/06/2014 08:39 AM, Nils Goroll wrote:
> Hi Federico,
> 
> I must say I don't understand the first part of your email about
> the delete keyword and what you intend to express about calling
> vmod methods.

Frederico had written:

> One of the reasons was to use malloc'd memory.

That sounds to me as if VCL authors become responsible for memory
management, in that they will have to free malloc'd memory, and could
create memory leaks if they forget to delete. But maybe I'm
misunderstanding, because it sounds very dangerous.

+1 to not understanding the bit about the VMOD methods.

>> A PRIV_REQ type will solve single state cases and has the extra
>> benefit of somewhat automatic clean up when the request is done.
>> 
>> Thoughts?
> 
> This has got a long-standing vote from me too, the request lives
> here: https://www.varnish-cache.org/trac/wiki/Future_VCL#VMODs :
> 
> * VMOD {{{PRIV_REQUEST}}} {{{PRIV_SESSION}}} state

+1 for PRIV_REQUEST and PRIV_SESSION, +2 or more if I could. I
actually thought they would make it into Varnish 4.0.

Another reason: Using the file descriptors as indexes into per-session
state tables means that you have to allocate a table that is much
larger than will usually be necessary. To be safe, it has to be as
large as ulimit -n, and then you worry about whether the Varnish
process owner can increase it ulimits.

That doesn't have to be so bad, if it's just a table of pointers, but
it's unnecessarily wasteful.


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.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIbBAEBCAAGBQJTaJqlAAoJEOUwvh9pJNURCzYP92KXuL0WgUGh4ngskE8ilvwW
yfsJFd8cOvipEZUcnhS8gVPGNpnoHToVQ1fe4+zWWsD+fZx2osneyN6Q9pv7tlRo
J3ei/moCnqQ1IwDyOdEVAWriV1x4jsxGR1uReFDqZCKmHzcOfzSkN8Osbel4gpXz
PDkRR/pkMM14iziXyFx2Bumb28fYsva+sKpK4237+x6WmQigVSOHpvCblb9jx3SK
Lz4E8BR63vGsB5e1dTofpyA4QKFIk8PdlSSm6rFYh+HELQiWabOmCJSskiwRycmi
ujnmGhFEBLEzAfjXLL3jx7rUqxb7d7ie/4DByTD6CEXm6qeVmOkboYGHfudu05EZ
HiTKNRItu9Q6+NZihbb4BgF0mC4SXgje/MlbsL9ldCBMnMScXxqulPGUCv+PoMLL
0I7zz6OC0HFqQxRuLy2I2M3+EMsjMCH/uXilLOhQJZOHOE9i68B8w01mx2rrkePJ
nXmSzpVC8hg2lAEOCliP5irtYFkNDgxZ/gDCVwcz8BZ6J0CDo6RNlUUnqTtsagBn
Bp88rBCKpeJzwCL5xprpHEB9kQtmsegDNrmhSaMK/KfHojdlflUK5hlcSxBrpGO9
Z7ZFJDGx4KWwzn/6ljBe86fbfjlTG0rgp8b5NzJiXdm37Squ+dsESIGPpaPdLMMS
xVbeYUnIbPy52o9c0UU=
=B6d0
-----END PGP SIGNATURE-----