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