<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello,</p>
<p>adding a new class of variables with such behaviour is ok.</p>
<p>The $var(...) has already a variant $vn(...):</p>
<p> -
<a class="moz-txt-link-freetext" href="https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#vn_name_-_private_memory_variables_null">https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#vn_name_-_private_memory_variables_null</a></p>
<p>$var() is initialized to 0, $vn() is to $null. iirc, there are
flags to make the difference, I think that can be reused to add
another type of private vars.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<br>
<div class="moz-cite-prefix">On 21/01/2017 09:20, Armen Babikyan
wrote:<br>
</div>
<blockquote
cite="mid:CAGDtNKA1qVRxsTiPvNpr5yP9FjJRUH2Y4kdgvTKLdyg+=KFDOQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Daniel,
<div><br>
</div>
<div>Thanks for your response.<br>
</div>
<div><br>
</div>
<div>Any thoughts to my later comments? i.e. would you consider
a patch that resets these variables between top-level
request_route executions, either by $var(all) = $null, and/or
modparam behavior, and/or something else?</div>
<div><br>
</div>
<div>BTW, is the current behavior done this way for a specific
reason or foreseen complication (i.e. one that I am not seeing
at the moment)?</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>Armen</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jan 18, 2017 at 6:35 AM,
Daniel-Constantin Mierla <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:miconda@gmail.com"
target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hello,</p>
<p>preparing the release of v4.4.5 and digesting the
sr-dev mailing list activity, I noticed that this was
not answered.</p>
<p>The $var(x) type of variables is not reset, they
persist over execution of the routing blocks. Their
values are stored in private memory, so they are like
global variables per each kamailio process/worker. You
have to reset them explicitly.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div>
<div class="h5"> <br>
<div class="m_4716459962514934510moz-cite-prefix">On
26/11/2016 00:19, Armen Babikyan wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">Hello,
<div><br>
</div>
<div>I recall reading somewhere that all private
variables (i.e. $var(foo)-style pvs) are
reset/destroyed between request_route
executions, but I have a suspicion this is not
happening - either in some limited cases or
perhaps in all cases.</div>
<div><br>
</div>
<div>I suppose the most telling symptom is that I
see no references to either destroy_vars() or
reset_vars() functions that are defined in
$kamailio/modules/pv/pv_svar.{<wbr>c,h}.</div>
<div><br>
</div>
<div>Is this behavior intentional? If so, I'll
see what I can do about implementing a mechanism
that manually resets (or destroys?) variables
with a "$var(all) = $null;"-type of statement
(similar to "$uac_req(all) = $null;"), or making
a modparam setting that automatically does this.</div>
<div><br>
</div>
<div>Thoughts welcome. Thanks!</div>
<div><br>
</div>
<div>Armen</div>
<div><br>
</div>
</div>
<br>
<fieldset
class="m_4716459962514934510mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
sr-dev mailing list
<a moz-do-not-send="true" class="m_4716459962514934510moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" class="m_4716459962514934510moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/<wbr>cgi-bin/mailman/listinfo/sr-<wbr>dev</a><span class="HOEnZb"><font color="#888888">
</font></span></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<pre class="m_4716459962514934510moz-signature" cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" class="m_4716459962514934510moz-txt-link-abbreviated" href="http://www.twitter.com/miconda" target="_blank">www.twitter.com/miconda</a> -- <a moz-do-not-send="true" class="m_4716459962514934510moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda" target="_blank">www.linkedin.com/in/miconda</a>
Kamailio World Conference - May 8-10, 2017 - <a moz-do-not-send="true" class="m_4716459962514934510moz-txt-link-abbreviated" href="http://www.kamailioworld.com" target="_blank">www.kamailioworld.com</a></pre>
</font></span></div>
</blockquote></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre></body></html>