is it about a global variable defined inside the perl script or you mean kamailio.cfg variables? The terminology you used might be clear for Perl guys, but as I am not one, I want to clarify it... As generic remarks -- kamailio is multi-process application, so each child is a process, not a thread. Each process has its own private memory space, so a global kamailio.cfg variable such as $var(x) is defined in each process and each process has access to the one specific to it. There are shared memory variables, like $shv(z) that all processes can access and change, requiring synchronization to avoid races. Cheers, Daniel On 13/10/16 19:13, Alex Balashov wrote:

My experience with app_perl is that global variables are not shared between processes. So if you have 10 kamailio processes you would have 10 different %hash with different values. So it is thread safe, but perhaps isn't what you want. Torrey On 13 October 2016 at 23:15, Alex Balashov &lt;abalashov(a)evaristesys.com <mailto:abalashov@evaristesys.com>> wrote: I meant a global Perl variable -- one that would persist in a persistent interpreter. Specifically, a "package variable" of this type: our %hash = (); On 10/13/2016 04:26 PM, Daniel-Constantin Mierla wrote: Hello, is it about a global variable defined inside the perl script or you mean kamailio.cfg variables? The terminology you used might be clear for Perl guys, but as I am not one, I want to clarify it... As generic remarks -- kamailio is multi-process application, so each child is a process, not a thread. Each process has its own private memory space, so a global kamailio.cfg variable such as $var(x) is defined in each process and each process has access to the one specific to it. There are shared memory variables, like $shv(z) that all processes can access and change, requiring synchronization to avoid races. Cheers, Daniel On 13/10/16 19:13, Alex Balashov wrote: Hi, Given the presence of a global (e.g. "our") package variable in an embedded Perl script used through app_perl, is there any implicit thread safety? That is to say, can a Perl function invoked by one SIP worker reset the value of a global while another instance of the function invoked by a different SIP worker is accessing it? And if so, is it safe to use generic perlthr locking to avoid this? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev> _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hello, it is a perl interpreter per process, otherwise it will need a dedicated process for it with some interprocess communication with the other worker processes and I haven't seen that in the code, in the few moments I was working on this module. Cheers, Daniel On 14/10/16 16:14, Alex Balashov wrote: have &lt;abalashov(a)evaristesys.com or clear one all to variable function -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev