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
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
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
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@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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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@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
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 <abalashov@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" ofthis 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
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 miconda@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
<abalashov@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" ofthis 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 scriptor
you mean kamailio.cfg variables? The terminology you used might beclear
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) thatall
processes can access and change, requiring synchronizationto
avoid races. Cheers, Daniel On 13/10/16 19:13, Alex Balashov wrote: Hi, Given the presence of a global (e.g. "our") packagevariable
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 thefunction
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.
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 miconda@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
<abalashov@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" ofthis 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 scriptor
you mean kamailio.cfg variables? The terminology you used might beclear
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) thatall
processes can access and change, requiring synchronizationto
avoid races. Cheers, Daniel On 13/10/16 19:13, Alex Balashov wrote: Hi, Given the presence of a global (e.g. "our") packagevariable
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 thefunction
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.
-
Alex Balashov -
Daniel-Constantin Mierla -
Torrey Searle