-----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----- _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
