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 <abalas...@evaristesys.com
<mailto:abalas...@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@lists.sip-router.org <mailto:sr-dev@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@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/

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to