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 <mico...@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 ><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 >>> >> >> > >-- >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@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. _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev