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

[Alex Balashov]

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.