14 Oct
2016
14 Oct
'16
7:59 p.m.
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:
--
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
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(a)evaristesys.com
<mailto:abalashov@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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev