[sr-dev] Thread safety of global variables used in app_perl

Alex Balashov abalashov at evaristesys.com
Thu Oct 13 23:15:37 CEST 2016


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/



More information about the sr-dev mailing list