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

Daniel-Constantin Mierla miconda at gmail.com
Fri Oct 14 20:32:40 CEST 2016


app_perl module has an option to reset the interpreter -- check to see
if that's enabled, it might affect what you do there.

Daniel


On 14/10/16 19:02, Alex Balashov wrote:
> Ah, I see. 
>
> The motivation for the question was an attempt to troubleshoot why the value of this hash is occasionally empty. 
>
> Every once in a while, it's set to empty and then  reloaded from the database (after x many accesses). The thinking was that perhaps another worker is trying to access this value at the same time that it was emptied in a different context. 
>
> However, if the interpreter instances are per-process, that theory is probably out. Thank you, Daniel! 
>
>
> On October 14, 2016 12:59:13 PM EDT, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
>> 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:
>>> Hi Torrey,
>>>
>>> I don't think that's how the app_perl module works. I believe it
>>> spawns a single instance of the interpreter that is shared among the
>>> processes. I could be mistaken, but that's how it looks from the
>>> module code.
>>>
>>> On 10/14/2016 03:22 AM, Torrey Searle 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
>> <abalashov at evaristesys.com
>>>> <mailto: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 <mailto:sr-dev at 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 at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>
>>>
>> -- 
>> 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> -- Alex
>
> --
> Principal, Evariste Systems LLC (www.evaristesys.com)
>
> Sent from my Google Nexus.
>

-- 
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




More information about the sr-dev mailing list