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

Torrey Searle tsearle at gmail.com
Fri Oct 14 09:22:26 CEST 2016


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 <abalashov at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20161014/4bd23fa5/attachment.html>


More information about the sr-dev mailing list