[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