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

[Alex Balashov]

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
>


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