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

[Daniel-Constantin Mierla]

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